In this class, we will finish with our final presentations and then Prof. Stephens-Martinez will close our last class day with a brief presentation on the class can what you can do in CER after this class.
On Tuesday, 12/6, or Thursday, 12/8.
The project presentation is intended to provide a high-level overview of your project to an audience of your peers and anyone knowledgeable in CS. CS faculty and anyone interested in CSEd will be invited to see your presentation.
The presentation should demonstrate your ability to communicate the significance and interpret the findings of your research project. The presentation should stand on its own so that it makes sense to someone who has not read any of your other work.
Each group will have a 20-minute slot. 10-15 minutes should be the presentation and the rest of the time is for questions. Everyone in the group should have a turn to present. The presentation is serving as a summative assessment to confirm each of you can comprehensively explain some aspect of your group’s work. If someone cannot make the presentation, we will Zoom them in so they can participate in the Q/A. If that is not possible, they should prepare a recorded video of their part of the presentation. I strongly recommend you practice as a group to get a sense of the timing.
I recommend starting with the order and content in your report. And then, set aside your report and talk your way through the presentation, reordering slides and points until it more naturally flows when explaining your project to an interested listener. Your presentation should include all of the following, but does not need to be in this order:
The presentation will be graded as the following pieces, each with our usual four-step rubric scale as follows.
All members of a team may not necessarily receive the same grade.
Due: Friday 12/9, late due Sunday 12/11
Your final report is a comprehensive account of your project and as if you were planning to submit it to a conference (without worrying about formatting). It should be written as if you had “planned this as your project all along.” A report is not a chronological story of your project. It is a summary of what you did where the “story” serves the reader’s comprehension. Just like all of the related work you have read is framed not as a chronology but as a summary of what was done and found.
The report should stand on its own so that it makes sense to someone who has not read your proposal or prototype. It should be 5-7 pages (not counting references) using standard margins (1 in.), font (11-12 pt), and line spacing (1-1.5) OR you can use the ACM standard 2-column template. A typical submission is around 3-4 pages of text and 5-7 pages overall with tables and figures. Your report should have a title and your names with netids.
For citations, use the same notation that is common in the ACM papers (SIGCSE, ICER, ITiCSE, etc.) and cite the work by saying something like “In Smith et al.’s [3] work, ….” Note the use of the [#] as an annotation as opposed to a noun “In [3], …”
You may also include an appendix with as many pages as you need. This should mainly be of tables and figures, not text. The only text that really belongs in the appendix is any captions that help explain tables and figures. However, the report should be understandable without the appendix. The appendix is just a place for supplemental and extra information. So when in doubt, if the reader needs something, just put it in the appendix unless you find yourself referencing it a lot.
You should convert your written report to a pdf and upload it to Gradescope under the assignment “Project Final Report” by the due date. Use the group submission feature on Gradescope. You do not need to upload your accompanying data, code, or other supplemental resources demonstrating your work to Gradescope; instead, your report should contain instructions on how to access these resources (see part 2 below for more details).
Your final report should begin by motivating your topic and stating your research question(s). In contrast to the prior reports, the final report does not need to explicitly justify that the research questions are substantial and feasible in the text; your results should demonstrate both of these points.
You can start with the text from your prototype, but you should update your introduction and research questions to reflect changes in or refinements of the project vision. And there should not be a section comparing this report with prior ones. Remember, this report is as if you had “always planned” to do what you did and were submitting it to a conference. Your introduction should be sufficient to provide context for the rest of your report.
This section should summarize the work you found that is related to your project. It should be organized by the big ideas and summarize the key takeaways generally with supporting citations. Remember the “how to write briskly” reading and that you can always use another paper as an example of how to write your own related work section.
This section should summarize how you answered your research questions and the results of that analysis. Often there are two “sets” of methods, the methods used to answer most/all of the research questions, like cleaning and transforming the data, and the methods used for a particular research question. The former should be in its own section, so the text is not repetitive. The latter is in its respective results section for the sake of proximity.
Your report should be specific about exactly what data were used and how the results were generated. For example, if you filtered out some of the data due to A and B reasons, you should state what criteria were used to filter the data, why, and how much of the data was filtered out (or is left). These steps should be explained in enough detail such that an informed reader (like another group working on the same data set) could reasonably be expected to reproduce your results with time and effort. Just saying, for example, “we cleaned the data and dealt with missing values” is not sufficient detail.
Results should be summarized using clearly labeled tables or figures and supplemented with written explanations of the significance of the results with respect to the research questions outlined previously.
Your report should also contain instructions on how to access your full implementation (that is, your code, data, and any other supplemental resources like additional charts or tables). The simplest way to do so is to include a link to the box folder, GitLab repo (share it with Prof. Stephens-Martinez’s netid email: kvs13@duke.edu), or whatever other platforms your group is using to house your data and code. Remember to keep the data private!
In this part, you should discuss any important limitations or caveats to your results with respect to answering your research questions. For example, if you don’t have as much data as you would like or are unable to fairly evaluate the performance of a predictive model, explain and contextualize those limitations.
Besides limitations, put any other discussions or ideas for future work here. This could be a discussion on an idea that explains the results you had, but you do not have the data to provide evidence for the idea. This could explain how future research might address the limitations you outline, or it could pose additional follow-up research questions based on your results so far. In short, explain how an informed reader (such as a peer in the class) could improve on and extend your results.
This section should provide the key takeaways from your work and should only be a few paragraphs at most.
If you are struggling to keep your report within the 5-7 page limit, you may move some of your figures and tables to an optional appendix that will not count against your page limit. However, your report should stand on its own without the appendix. The appendix is for adding more nuance to your results, not to give you more space to talk about your results. Succinctness is an important skill to practice. Your paper will be graded without looking at the appendix.
Each section will be graded on a four-step rubric scale as follows.
The entire assignment is worth 100 points.
The rubric will be converted to points as follows:
Anything earning less than an E will receive feedback in Gradescope. If your proposal earns less than an S in any section, you will be allowed 2 resubmissions to bring it up to the E or S standards for all sections. If your report earns E’s and S’s only, you can have 1 resubmission if your group decides to aim for a higher score. I will aim to give you feedback by Tuesday, 12/13, so a resubmission must be given by Friday, 12/16.
For this class, we will start with a presentation by Shao-Heng. He will be practicing his presentation for his SIGCSE TS 2023 paper “What Drives Students to Office Hours: Individual Differences and Similarities.” This presentation will serve as an example of what a polished Exemplary talk looks like to give everyone an idea of what kind of talk to strive for the following week. Note that Shao-Heng’s talk is polished by getting a lot of feedback from me and will not be used as the floor of the Exemplary standard but as something to aim for.
Then, we will have another writing workshop with the goal of writing an abstract about your project. These abstracts will be included in Prof. Stephens-Martinez’s advertisement to the CSEd faculty in the department, inviting them to come to see your presentations. Besides getting feedback on your abstract, you can get feedback on anything else, including your presentation next week.
Your abstract is due Thursday, 12/1 (the day of this class), at 11:59 PM. Your abstract should be 1-3 paragraphs and no more than half a page long. Formatting is not relevant since you will submit via an open textbox in Gradescope.
At this point, you’ve read many abstracts, so you should feel free to draw on what you’ve liked and not liked about those abstracts. The following should be included in your abstract:
This will count as 1% of the project presentation’s 12% for your overall grade.
We will spend most of the class period doing one-on-one group check-ins. You will have feedback from your prototype by this day, so you can use the time to go over this feedback. When not meeting with Prof. Stephens-Martinez, plan to work or meet with your group, like a writing workshop.
Make sure to fill out a group check-in slide!
In the last 30 minutes, we will have Prof. Brandon Fain visit again to continue our conversation from last Thursday. To prepare for the discussion, answer the following questions in your QQC Docs the day before, Wednesday 11/16.
Read the following in The Cambridge handbook of computing education research of Chapter 14 “Assessment and Plagiarism.”
For the first part of the class, we will have group check-ins. Make sure to create a slide like usual.
In the last 30 minutes, we will have Prof. Brandon Fain as a guest speaker. He will talk about how theory and algorithms are taught, how it’s motivated/connected to practice, how people learn it, how it’s assessed, and what’s known and what isn’t really well known about it.
Reading (Also in Box folder): Maria Knobelsdorf, Christoph Kreitz, and Sebastian Böhne. 2014. Teaching theoretical computer science using a cognitive apprenticeship approach. In Proceedings of the 45th ACM technical symposium on Computer science education (SIGCSE ’14). Association for Computing Machinery, New York, NY, USA, 67–72. https://doi.org/10.1145/2538862.2538944
In your QQC Doc the day before class (11/9), write the following reflection, which will count as an assignment:
This will be out of 10 points:
If you do not score a satisfactory, you can update your reflection and submit a regrade request via email. Use the subject line “CS290: Regrade Teaching Associate Reflection.” Please request a regrade by 11/15.
For this week’s reading, you may choose a chapter in the handbook or find a paper from the following CER journals. If it is not open access on the hosting website, try using Google Scholar, Duke Library, or the author’s home page to find a freely available copy. Contact Prof. Stephens-Martinez if there is a paper that you want to read, but it is behind a paywall, and she can try to help you get a copy.
Warning: Journal papers are often longer.
There are two deliverables for all BYOPapers:
In your tables, you will discuss what labels to apply to your paper (and if you didn’t present a prior BYOPaper, that paper as well) and any new labels that would make sense to have. Then we’ll come together and have a class discussion about the papers.
You may redo the work and request a single regrade to update your grade.
We will spend the entire class period on group check-ins on this day. If we get through all of the check-ins before the end of class, we’ll spend the rest of the time on more one-on-one meetings with Prof. Stephens-Martinez or each respective group. Make sure to fill out a group check-in slide!
Read the following in The Cambridge handbook of computing education research of Chapter 16 “Equity and Diversity”
16.4 Conclusion (0.5 pages)
Add an entry about this reading to your QQC Doc.
|