Proposal Presentation Rubric#
Because this is an online course, we put extra emphasis on getting to know each other and learning from one another’s work. A central part of the final project this term is the proposal presentation: each group presents the plan for their final project to the class, advertises the “product” they intend to build, and gets live feedback from their classmates.
This page explains the full procedure and how the proposal presentation is graded. See the Final Project Instructions and Rubric for the project itself.
The Three Separate Events#
Your final project involves three distinct events. They are separate—do not confuse them.
1. Instructor Consultation#
A 1-on-1 meeting between your group and the instructor.
When: You must schedule it to occur at least one week before your group’s proposal presentation.
How to schedule: Use the booking link—https://finm-32900.youcanbook.me/ (also posted on Canvas). You are responsible for scheduling this yourself.
Purpose: This is where you get individual feedback from me on your plan before you present it to the class. Come prepared with your project idea, your data sources, a rough plan for the product you want to build, and the division of responsibilities between the two team members.
2. Proposal Presentation#
An in-class presentation to the whole class over Zoom.
When: In an assigned week, roughly weeks 5–8 (extending into week 9 if needed). With about 12 groups, roughly three groups present each week.
What you present: Tell the audience
what your paper/project is about,
what data sources it uses, and
the product you plan to build and why it is interesting and useful. This is an advertisement: convince your classmates why they would want to clone your repository and run your code. Describe your own new table and figure and what they reveal, and explain what you are contributing (e.g., a cleaned, shareable dataset and the code to produce it).
Live feedback: Classmates ask questions during your presentation, and every student fills out a peer-feedback survey about your proposal. The survey is written to help you: it asks the audience to say, in their own words, what your paper is about and why it matters, whether they would actually use your replication code and your proposed extension (and specifically how), and how clearly you explained each. This shows you whether your message landed and whether classmates see real value in what you are building. I use the aggregated feedback to help grade your proposal (see How the peer feedback is used below).
When the survey happens: You will get a few minutes of quiet feedback time in class right after each group’s Q&A, and the form stays open until 11:59 PM the day after the presentation so you can revise or expand your comments. The link is posted on Canvas and pasted into the Zoom chat.
3. Final Project Presentation#
In week 10, your group presents the completed project, and each member is individually quizzed in an oral defense. See the oral-defense item in the Final Project Rubric.
How Presentation Weeks Are Assigned#
You will indicate your project preferences and your availability to present in one of the proposal-presentation weeks using a Google Form (link TBD, posted on Canvas). I will use your responses to assign each group both a project and a presentation week. Once you know your assigned week, it is up to you to schedule your instructor consultation for the week or two before it.
Grading#
Proposal Presentation — 20% of the course grade#
The proposal presentation is graded primarily on:
Ambition (8 points) — Is the project and proposed product appropriately ambitious? Are you going beyond a mechanical replication to build something genuinely useful?
Usefulness and interest of the product (8 points) — How useful and interesting do your classmates judge your proposed product to be? This is informed by the aggregated peer-feedback surveys. Have you made a convincing case for why someone would want to use your data and code?
Clarity of the data sources and analysis (4 points) — Did you clearly explain what data you are using and what your additional table and figure will show?
Points are prorated by discretion based on the difficulty of the underlying project.
How the peer feedback is used#
The peer-feedback survey is qualitative by design, but it maps onto the three grading criteria above:
Usefulness and interest (8 points) is informed most directly by the audience’s answers to “would you use your classmates’ replication code / proposed extension, and how?” Concrete, specific intended uses are the strongest signal that a product is genuinely useful.
Ambition (8 points) is informed by how the class describes your proposed extension and the significance of the underlying paper — whether they see it as going meaningfully beyond a mechanical replication.
Clarity (4 points) is informed by the two 1–5 clarity ratings (how clearly you explained the replication, and how clearly you explained the extension), corroborated by how accurately the audience was able to restate your paper and your product in their own words.
Proposal Attendance & Feedback — 10% of the course grade#
Networking with and learning from your classmates is an expected part of this course, so attending the proposal presentations and giving thoughtful feedback is required.
For every proposal presentation, you must both (a) attend (Zoom attendance is taken) and (b) submit the peer-feedback survey for each presenting group.
Both are required to earn the points. There are no allowed misses—you are expected to attend all of the proposal presentations and give feedback on every group.
Your feedback is not only a grading input for the presenters; it is how the class learns from each other’s projects, so please make your comments substantive.
How attendance is recorded: Your name and the timestamp on each survey response are the attendance record, and the Zoom participant report is the backup and cross-check. The form stays open until 11:59 PM the day after the presentation, so submitting a thoughtful response by then satisfies both the attendance and the feedback requirement.