Project 5B & C: Project Presentations, Final Report, and Reflections

Deliverables

Project Report and Presentation – due Sunday, April 28th, 11:59pm

• Project Report (200 pts)
• Extra Credit (20 pts)
• Project Presentation Slides (100 points, graded based on presentation)

Presentation Date – Monday, April 29th, 5:30-8:30pm, during exam timeslot

Reflection – due Monday, April 29th, 11:59pm

• Reflections & Peer Review (20 pts)

Contributing to Open Source

You should perform adequate quality assurance activities when writing code.

1. Take further steps to understand the project’s code
   You might find it useful to engage in intra-team discussions using static or dynamic diagrams. You might also find it useful to elicit feedback on your ideas by communicating with members of the open-source community.

2. Submit your changes to the project
   Create any necessary documentation to enable acceptance of your code. Common contribution mechanisms include pull requests, emails to a project lead, or discussion board posts. You may also need to update the bug database. The project owners will review and evaluate your pull request, and you might need more work to get it approved.
   You are required to submit your work to the open-source project

3. BONUS: Get your changes accepted
   You will get a bonus 20 (5%) bonus points upon acceptance. If your code is accepted after the homework deadline but before final grades are released, inform the course staff.

Report, Presentation and Reflection

You will report on your project and task selection, work, and experience in several ways (see below). This will include a group presentation to the class.

Project Presentations (100 pts)

The Final Exam time is dedicated to group presentations (in-person) about your open source contributions.

• Presentations are 4 minutes long, with 2 minutes Q&A.
• The order of presentations is randomly determined.
• Participation from all team members during the presentation is required.
• Every individual will be asked to provide constructive feedback for other presentations in class via an paper form (which we will provide day-of).

Presentation Attendance

For full credit, you would have to be on time for the presentation session (within 10 minutes of start time). If you are unable to attend in-person, you have to send an email with justification to all instructors and cc your recitation TAs at least a week before your final exam timeslot so that appropriate arrangements can be made. Exceptions to notification deadline will only be made for unforseeable circumstances.

The goal of the presentation is primarily to share with the class the project to which you contributed, and your experiences. Your presentation should cover the following topics (the recommended slides amount is in parenthesis):

1. High-level Project Overview (~1 slide)

   • Describe the project in terms of its high-level goals and the context in which it operates. This may include a brief history and the business context. E.g. it may be interesting to note that a project was spawned from a closed-source operation, or that it competes primarily with a closed-source counterpart.

2. Brief Task Description(s) (~2 slides)

   • Brief description of the task(s) you performed, such that the audience has sufficient context to understand your explanation of your experiences.
   • Include a demo of your contribution(s), if applicable. Please do a screen recording of your demo instead of a live demo.
   • We do not expect you to include, for example, any code or diagrams from your report, unless they’re helpful for supporting a point about your interactions with the project.

3. Your Experiences (~1 slides)
   Summarize your experiences (and what you learned!) interacting with this community of open source developers, focusing on any surprising or unusual aspects of the process or interaction. For example

   • Did you run into any trouble understanding, changing, or contributing to a large, pre-existing project?
   • Were there unanticipated challenges in either implementing your change, or in getting the change submitted to and accepted by the project maintainers?
   • Did the project collaboration process or culture help or hinder your effort in any way? Characterize any interaction you had with the team leadership and community, highlighting especially any useful/useless input you received. You may (but are not required to) also relate the experience from this homework assignment with relevant experience from internships or other projects.

   Your summary of your experiences can be at whatever level of detail you think is interesting or informative. Given the time limit, selecting and highlighting the one or two most important or interesting observations is likely more useful than trying to be complete.

You must upload your slides as a single PDF document to Gradescope by Monday, December 11th, 11:59pm.

Project Report (200 pts)

After completing and submitting the modification, write a report about the tasks you have performed.

Your report should include:

1. Selected Project (1 paragraph)
   A brief description of the open source system to which you contributed. You may reuse text from Part A.

2. Project Context and Business Model (<0.5 page)
   An analysis of the open-source project’s context and business model. This may include a short history of the project, competing open- and closed-source projects, or a discussion of the developers’ motivations to build this system. Essentially, we want to know why this project exists and why it is important.

3. Project Processes and Communication (<1 page)
   Describe the processes and tools the project uses to coordinate among contributors. For example: Are these processes formal or informal? Provide an explicit description (possibly with a diagram) of the acceptance process used for efforts like the task you completed. If applicable, include standards or expectations regarding software engineering activities including requirements, architecture, and quality assurance; alternatively mention that no such standards exist.

4. Task Description (per task) (<0.5 page)
   A description of the tasks you have implemented and a high-level description of how you implemented them.

5. Submitted Artifacts (per task)
   Evidence of the code, documentation, or other artifacts you produced for the task, and evidence that you submitted them to the project. This would likely be links to publicly available resources (repository, email, pull request, etc).

6. QA Strategy (<1 page)
   Describe which QA activities you performed and justify why you selected these QA activities over others. Describe metrics if appropriate. The justification will likely refer to relevant requirements as well as to the project’s practices.

7. QA Evidence
   Evidence of your quality assurance activities described above. For example, provide source code or links to source code of tests, provide test protocols, comments or protocols from code reviews, reports from static analysis tools, links to or screenshots from a continuous integration platform, and so forth.

8. Plan Updates (<1 page)
   A description and justification of deviations between your initial plans and your performed activities (as in Homework 2). Changes are expected, but they should be tracked and explained. Describe changes in scope (e.g., fewer tasks) and in the schedule and work allocation. Provide an updated schedule and note differences. Explain the causes of the changes, such as unanticipated risks.

9. Summary of Final Contributions (<0.5 page)
   A table that briefly summarizes the contribution(s) each team member made towards completing the task(s).

10. Extra Credit
    Evidence that your changes have been accepted into the code base of the open source project in forms of links or screenshots. Note: You can also send the merged PR link to the instructors and Sophia via Slack over Group DM or e-mail(to all) by 3rd May 1pm to claim this bonus as well

Page limits are provided for guidance; we will not enforce them. Collect all parts in a single PDF document with clear subsections and the names of all team members and submit that file to Gradescope.

Individual Reflection & Peer Evaluations (20 pts)

Contributions

We want to ensure that everyone is participating fully in the final project. For this project, we will be assessing participation in a variety of ways, including: artifact evaluation, self & peer evaluation. Credit due for the team components of this project will be awarded based on evidence of full participation in the team. Partial participation will receive partial credit.

Use of Generative AI Forbidden

As described in the syllabus, the use of generative AI tools for this part of the assignment is forbidden, and will be considered to be an academic integrity violation.

Your individual reflection should include:

1. Self Evaluation
   Describe the work you have done in this project (e.g. code artifacts, documentation) as well as efforts towards helping your team towards completing this project (e.g. research, organizing meetings, running meetings).

2. Peer Evaluations
   Describe the specific work each of your team members have contributed towards this project. Describe both tangible (e.g. code artifacts, report & slides making, documentation) and intangible (e.g. organizing & running meetings, communicating expectations) contributions. Do point out teammates that you think are exceptional to work with in this project as well.

3. Teamwork
   You have been in the same team over the course of this semester (Projects 2-5). Look back on the entire semester and reflect on your team experiences. The following questions may guide you:

   • What has worked, what hasn’t?
   • If you could start 313 or another course over with the same team, what would you change?
   • What have you learned about teamwork and your role in teamwork?
   • (Optional) Do you have any feedback on what we can do next year to help students work more effectively in teams? Bear in mind that the instructor-assigned heterogeneous teams of 3-5 students is non-negotiable. We anticipate problems as part of the learning experience, but would like to avoid unduly frustrating situations.

A good reflection document will include concrete statements about lessons learned, with clear supporting evidence, such as examples, to support them. Submit your reflection on Gradescope.