MIT 6.S194 | Open Source Software Project Lab  

Final Presentation

When

Final presentations will be on Monday, May 6 and Wednesday, May 8. We'll do three presentations one day and two the other. Please email me to let me know your preference.

Everyone must attend both days. If you can't attend one day, make sure you email me in advance (and make sure that's not the day your group is presenting.)

  • Monday: Phabricator, Review Board
  • Wednesday: MongoDB, Ruby on Rails, Socket IO

What

Provide a debrief of your project, with four main components:

  • Introduction. A concise introduction of the project you worked on. (Even though you are all familiar with each other's work, we may have some guests visiting the final presentations.)
    • What is it?
    • Why do people use it?
    • What software architecture does it employ? (language? client? server? client-server?)
  • Accomplishments. Describe what you worked on this semester:
    • List your group's accomplishments. Don't sell your self short. Instead of saying "we fixed some bugs", list those bugs for us. No bug is too small.
    • Give us the context around the accomplishment. If it is a bug fix, what was the error it fixed and what is a narrative of a situation your fix prevents?
    • If appropriate, feel free to show a demo or high-level code example.
    • Tip: It's great to walk the audience through the steps required to make something happen, with code examples or diagrams. I.e., "First the server sends this message. Then the client catches it. Now a choice happens. If this event occurs, then this other thing will happen.. but here's the bug! So we need to figure out how to resolve this while still retaining this other functionality... " etc.
  • Team Structure Takeaways. How did your remote team and mentors work with you? How did the core team (not counting you) work together? Consider meetings, information exchange, bug tracking, feature discussions, feature planning, etc.
    • What are some aspects of this that seemed to work well. A good heuristic for this is whether you would replicated it in your own project.
    • What are some aspects that you think need improvement?
    • Pick one or two major take-aways that you think the rest of the class should hear. (e.g.: "having mentor 'office hours' is a really good idea since creates a casual atmosphere" or "this part of code reviews is helpful, but this part isn't")
  • Project and Code Structure Takeaways. Tell us about the code design from a high level, with a similar approach to the team structure takeaways.
    • What are some aspects of the way your project code is organized that you think was great? Their use of a particular framework? Support libraries for defining APIs? Their coding style? Which parts will you seek to replicate on future projects?
    • What aspects weren't great? What did you have a hard time with? Don't be shy: if something was challenging, weird, or hard, it's interesting to talk about.
    • Anything cool/interesting that you think everyone should hear about coding style or architecture?

    • Mechanics

    • Who? One presentation per group. Everyone in the group should speak.
    • Time. Shoot for between 15 and 20 minutes. Larger groups should err on the side of more content to present.
    • Code. Unlike Design Reviews, code is not required. If you include code, it must fit on the slide in at least 16pt font. Pseudocode encouraged: think high-level.

    Final Note

    Each of you was dealt a completely different hand of cards with this class, and I am really proud of how played them. Some projects have been one big task, others a series of small ones. Some well defined, others open-ended. Several of you have started something, and then realized later it needed to be re-designed or even abandoned due to information you later learned.

    You've all worked hard and done great work, and you've helped the larger community during the process. Every one of you deserves to be proud of the work you'll present.