1. are individual
2. should consist of:
   1. <=5 sentences summarizing the paper *in your words*
   2. a bullet list of 3 positive and 3 negative points
   3. a longer explanation/motivation of the 3 positive and negative points
   4. a score for the paper going from -3 (strong reject) to +3 (strong accept)
   5. should be submitted via Reviews => My papers => [correct] => add new review (ignore the Subreviewer, Confidential remarks and Attachment fields, and pick a random value for Reviewers confidence)
   6. should be submitted *before* the start of the class in which the paper will be presented (by a colleague)
   7. reviewing criteria to consider (feel free to add others):
   8. novelty of the contribution
   9. quality of the approach
   10. correctness of the empirical analysis
   11. how interesting are the results? are they actionable?
   12. any related work that was missed?
   13. potential ideas for future work?

1. are individual
   1. should be 15 minutes
   2. will be followed by a group-wide discussion, so even if you are not the presenter/reviewer, please come prepared to class
   3. should follow the presentation guidelines that have been posted on Moodle (e.g., the slides should be in English, while the talk can be given in French, if desired)
   4. should be submitted using the same procedure as for reviews (this can be done after the presentation, on the day of the presentation), except that you should attach your presentation as an Attachment instead of typing in a Review.
2. The goal of the presentations and papers is to make yourself comfortable with presenting/reviewing/discussing research papers, as well as to learn new techniques or important results in the field. For those reasons, I would recommend to also read the papers presented/reviewed by others, since that will allow you to participate in the discussions (which count for 10% of the marks).

In easychair: MAYBE = reviewing, YES = presenting

1. Two people group
2. Implement existing research methodology in my dataset
3. Proposal
4. What they did
5. On what data we are doing it
6. Our results
7. Compare our results with the existing one
8. Discussion the differents
9. Threats to validity

1. Individually
2. Proposal
3. Research questions
4. Data
5. Methodology
6. Defects

• Number of active switches across releases
• Code blocks gaurded by flags
  • Is the block a function/sub body inside?
  • LOC of the blocks
  • Nested switches
• Commits with only switch files ~ Commits with switches and other files
• People who are toggling or adding the switches
• Conditional compilations [#ifdef]
• Relations with Releases

1. What is features flags, How are flags being used 2. How many total flags in google chrome, how many of them are active and how many of them are inactive. 3. How many commits are made for flags/toggles in google chrome 4. How much churn are made for toggling/blocking codes 5. Why flags enabled or desabled most of the time 6. How much time between a switch being active and be removed

Readings: The card sorting