Meteor Studio Handbook
This handbook is intended to familiarize you with the policies of our studio. This is not intended to create arbitrary rules, but to encourage effective research as a team member of the studio. I hope these come across as reasonable, guided by natural, common sense.
Please read all of it.
Immediate TO-DO items for new folks:
- Please join the Slack workspace. (Email me if you haven’t been invited yet)
- How to log hours: [Link] (Do NOT mention backlogged hours in your pay comments!)
Our mission
Meteor Studio is an educational environment, geared for training graduate and undergraduate students to become high-potential researchers, engineers, designers, and artists, primarily through applied research and design projects.
Its mission is to grow students to become innovative leaders, equipped with:
- Forward-looking aptitude and scholarship;
- Imagination and whimsy;
- Professionalism and integrity; and
- Resourcefulness and mindfulness.
Mindset: You’re awesome, and we need you.
You’re part of our team because you’re here to help us carry out our mission! All members, regardless of their tasks and projects, are part of building up our culture. This is especially true for Ph.D. students and other project leads, who should take leadership and initiative in their project directions. But it’s true of all artists, designers, and engineers at all ranks. So take some time to dwell on the mission statement above.
Basic Professionalism Guidance
-
Communicate any impediments or roadblocks as swiftly as possible: You are the owner of your work, but you are not the only stakeholder. If you get stuck or are moving slowly, please communicate this immediately. Don’t wait for a deadline to expire! It's best not to wait for a weekly meeting to explain that you weren’t able to achieve a task. Instead, Slack about the impediment or slow pace well before the meeting.
-
As a rule of thumb, if you’re going to break expectation, break it sooner than later. It is also fine to say “I’m stuck on this, but I’d like to work on it a little more before asking for help.” I want to re-emphasize: Do not try to prove competence by completing something before communicating. It is far more impressive when someone says, “This thing is in progress, but I’m trying X, Y, and Z still.” This is more fun for your teammates too, since it gives the ability for them to inject their own opinion into how the next steps should go.
-
Communicate on the same level on your team: Treat each other as colleagues, including your project leads, and including me. Leads, help your teammates be comfortable with being on the same level and be open and transparent with all work-related matters.
- Avoid: “Is this what you want?” (It’s not about what Robert wants!)
- Preferred: “Is this what we need to be doing?”
- Avoid: “Do it because I said so”
- Preferred: “Give this a shot, let’s see what happens.”
-
Communicate any deviation from a previous agreement: If your team agrees on something together (e.g., a strategic path for development) and you can’t stick to it (or don’t want to stick to it), that may be fine. But communicate that with your team and me that, e.g., over Slack/email, before deviating. Walk through your reasoning. This should be the case for writing, engineering work, or anything else.
Ultimately: You are free to deviate, but discuss!
-
Communicate with responsiveness over Email and Slack: During working hours, emails and Slack messages should be monitored in real-time as they come in. But only during your working hours; if you’re not working on the weekend, you don’t need to reply immediately. And of course, you can make exceptions for when you want to enter “deep work” (probably accompanied by a Slack status so we know not to bother you).
Rule-of-thumbs:
- Stay in tune with everything in your project teams and in the Meteor #general channels and #random channels.
- Participate in other channels too, e.g., #research and #technews.
- Emoji things that you see with your reaction. Be connected!
- Reply promptly to emails/Slacks. Otherwise it feels like messages disappeared into a black hole! Ideally, during working hours, you should reply within 1-3 hours, or even less. A reply saying “Ok” (or a thumbs-up emoji) is often good enough.
-
In your reply, it is helpful to put an estimate of how long it takes to complete tasks. Examples of acknowledgments:
- “Ok. I’ll read it tonight.”
- “Ok. I’ll start coding tomorrow, but it’ll probably take me until next week to finish.”
- “Got it. Let’s chat at our next meeting.”
- You can “Set yourself as away” in Slack’s status bar to make it obvious that you won’t see/reply. You can set your status if you want to.
- Set your Slack status for vacations with a date of when you’re coming back.
You can email/Slack Robert for whatever reason at all hours and all days. He may not respond immediately, but don’t worry about feeling judged about the time of day you send something, and don’t worry about irritating Robert.
Weekly Meetings
Each project should have a 30-minute weekly meeting time. The nature of these meetings should follow this general pattern:
- Where you were in your progress as of last week.
- Challenges/Insights/Obstacles/etc. that you faced this past week.
- What your plan is for next week.
Make sure to take good notes at each meeting. For large teams, appoint a notetaker prior to each meeting. It’s also helpful to have a meeting agenda, especially for complex teams/projects.
After each meeting, make sure to update your Jira board accordingly.
Addressing Personnel
All personnel in the Meteor Studio are colleagues with one another. Colleagues refer to each other on a first name basis. In academia for computing, this is common. In my industry experience, lab directors, vice presidents, and even corporation presidents are referred to on a first name basis. President Crow goes by Mike within his staff. Thus, you should call me Robert.
However, you should be deferential and respectful to professors outside of Meteor Studio, and call them Professor [X] or Dr. [X] until they invite you to call them by their first names.
Similarly, students who are taking my classes should call me Dr. LiKamWa or Professor LiKamWa in the context of my classes. When you interact with students outside of Meteor Studio, you should refer to me as Dr. LiKamWa to avoid confusion.
Speaking English
You should take every opportunity you have to improve your English skills, no matter whether you are a foreign student or a domestic student. This includes conversing with each other, but also conversing with those outside of the lab. Pay attention to try to communicate in perfectly correct English. Mind your spelling and grammar.
Also, I am not mandating that you only speak English. You may speak whatever language you want! However, when you are in the presence of an external guest (e.g., if Pavan is in the lab, or we’re walking back from lunch with Byron), you must switch to English. Otherwise, that visitor may feel alienated. This is even the case if I am having a conversation with that person and not involving you.
Ph.D. Student 1:1s
All Ph.D. students should have a 1-on-1 meeting with Robert. In these, we will discuss papers that you’ve read, research progress, ideas that you might want to pursue, paper writing, strategy, and really, anything that’s on your mind.
Conference/Journal paper submission deadlines/formats/etc.
Submission requirements and deadlines are 100% the responsibility of the lead author (the student). Students should read the “call for papers” extremely closely and make sure everything adheres to the conference/workshop/journal standards. This includes all aspects of paper format, submission protocol, and submission deadline. Remember that faulty paper format is reason to get summarily rejected without review comments!
Expected Daily Reading
All graduate thesis students are expected to spend an average of one hour per day reading research material/papers. Try to do this at the same time every day, when you are most comfortable with reading. My reading period is in the morning. Your research literacy will drastically improve if you make this a habitual practice.
If you’d like, send me an email when you begin and when you end with the name of the material you’re reading. This email schedule can set a rhythm with yourself in which you’re accountable to someone else. It also keeps a log of what you’ve read. If I haven’t read a work, I will likely try to read the work so that I can have a conversation with you about it.
Plagiarism
Read this fully to understand what constitutes plagiarism: Harvard's guide on plagiarism
Note that even if you copy text, change a few words here and there, and then cite the source, it is still plagiarism. Thus, the safest measure is to NOT copy the text, and instead write things fresh.
Even in your own notes, if you’re copying/pasting from a source text, surround it with quotation marks. For convenience, it would also be good to say what source you copied from. This way we will not make mistakes.
Date formats
When you upload things, e.g., presentations, your file title should be prepended with YYYY-MM-DD. For example, 2016-08-25. This format is standardized as ISO 8601. See: xkcd on ISO 8601 This makes the files sortable. Feel free to include an optional subtitle, e.g., “2016-08-25: AOSP Kernel”.
Equipment
Our equipment closet is in Stauffer B204, in the hallway by our lab B203. The code is 70641.
[Equipment policy forthcoming...]
Physical Presence
While no fixed office hours are necessary, it is good to overlap working hours with other Meteor members. I strongly recommend that Ph.D.-track students are present during “normal” working hours, i.e., make sure part of your day includes 1 PM - 5 PM (minus classes).
Hourly workers
Instructions on how to log hours are in this document.
Equipment
Equipment should not leave the lab unless explicitly allowed by Robert.
Aaron Toyne is our equipment manager, so consult him for all purchases/procurements.
Purchase Request for equipment/software
Please refer to this document for how to request new equipment for purchase.
Software purchases require a security review from HIDA IT.
Communicate about broken equipment
If you break a piece of equipment or find a piece of equipment broken, you should speak out about it immediately to the rest of the team, including me. This is especially crucial if it’s a shared resource, such as our computing equipment.
Even if you’re working on fixing it, it would be good to alert people that it’s broken and you’re trying to fix it. They might have suggestions.
Calendaring
Use Google Calendar to schedule events.
TBD
AME Faculty and Staff
More info about the School of Arts, Media and Engineering