b85169f4e7
- PhD defense slides (defense.key, Nov 2018) → phd_defense/ - Master's defense on MOOC peer evaluation (Dec 2014) - ENGI 600 data-driven program repair (Apr 2015) - COMP 600 data-driven program completion (Fall 2015, Spring 2016) - COMP 600 Program Splicing presentation + feedback + response (Spring 2018) - Program Splicing slides in .key and .pdf formats (Spring 2018) Each file has a .md transcription with academic frontmatter. Skipped www2015.pdf (duplicate of existing www15.zip) and syncthing conflict copy.
66 lines
2.1 KiB
Markdown
66 lines
2.1 KiB
Markdown
---
|
|
category: academic
|
|
type: academic
|
|
person: Yanxin Lu
|
|
date: 2018-03
|
|
source: comp600_feedback_2018.pages
|
|
---
|
|
|
|
# COMP 600 Presentation Feedback
|
|
|
|
Peer and instructor feedback on Yanxin Lu's COMP 600 presentation (Program Splicing), March 2018.
|
|
|
|
Good pace for the motivation part which explained the problem really well.
|
|
Stance is not good. Kept moving. Kept looking back to the screen.
|
|
Not really smooth in the beginning of the talk.
|
|
Related work is a little bit long which takes a lot of time.
|
|
Energy is not enough when introducing program splicing.
|
|
Good pace for the demo. But I was moving all the time. Need to stand still.
|
|
|
|
Kept moving in the architecture slide, and kept looking back.
|
|
Good gesture for demonstrating the KNN search.
|
|
PDB went a little bit fast. Need more details.
|
|
|
|
Enumerative search could be faster and don't need to show the process of enumeration.
|
|
Kept moving all the time in the benchmark problems.
|
|
Not very smooth in the benchmark problems.
|
|
|
|
Too much text in the user study slide.
|
|
|
|
Not smooth in the user study result slide, especially in the sieve problem.
|
|
|
|
Stance is not good through out the talk.
|
|
Went a little bit fast at the end of the talk because of time.
|
|
|
|
**Best feature**
|
|
1. PDB and related work could be shorter.
|
|
2. The motivation, example makes the problem easy to understand.
|
|
3. Mention the limit of the related work.
|
|
4. Good demo
|
|
|
|
1. Confident
|
|
2. Good voice control and eye contact
|
|
|
|
1. Tables were well explained.
|
|
|
|
1. Good handling questions.
|
|
|
|
**Message/organizations**
|
|
1. Need more technical details.
|
|
2. Source code license has to be covered
|
|
3. Demo was not very useful while a few slides can do the work.
|
|
4. Programming problems might not reflect the real-world improvements.
|
|
5. Explain more on the experiments.
|
|
6. Need statistically significance and power for the hypothesis test. Too few samples.
|
|
7. Not clear what the contribution is
|
|
8. Not mention limitations of the work.
|
|
9. The example in the demo might not be a good one.
|
|
|
|
**Delivery**
|
|
1. Keep his stance
|
|
2. Not showing enough passion
|
|
3. Louder
|
|
|
|
**Visuals**
|
|
1. Architecture flowchart could be made better
|