The group project for the course has a fairly open ended goal: you are to produce some app to effect positive social change, likely working alongside someone who cares about the results of your hard work.

The project will be graded as follows:

  • Group portion [70%]:
    • Weekly update emails [20/70%]
    • Final product [30/70%]
      • Graded 1/5:
        • 1 (0%): Totally incomplete, very little evidence your group even tried
        • 2 (10%): Some progress, but not very much, no app that represents serious progress towards the final goal
        • 3 (20%): At least some major feature of the app is done, but overall the app is mostly incomplete: major features are left unimplemented, and app occasionally crashes
        • 4 (25%): App is mostly there. Might occasionally crash, but has most features, overall feels like it’s mature.
        • 5 (30%): App is totally done, does not crash basically ever, is well tested, etc.. Overall: feels very mature.
    • Development style and maturity [10/70%]
      • I will read your code and give it a score from 1/4
        • 1 (0%): Your code style is totally inconsistent, you have no tests, it feels very buggy and ill-designed.
        • 2 (7%): I can read your code and it makes some sense, but you have very few tests, I feel like major parts of the design are very poorly thought out (e.g., lots of repetition), etc..
        • 3 (12%): Getting there, your code largely seems sensible, but not as many tests as you could have, it seems clear that it could make more sense, have more tests, etc..
        • 4 (15%): You have a very clearly-defined coding style (even perhaps with a document in your top-level directory that specifies the coding style to use) that everyone in your group is following, you have tests for most things, and your implementation feels very professional.
    • Project presentation [5/70%]
      • You will give a 25-minute project presentation at the end of the course. I will rate you 1-5 on various axes I will specify closer to the time.
    • Evaluation from your mentor [5/70%]
      • I will reach out to some mentor and ask them to rate their interaction with you. I will ask not about whether you achieved their perfect vision, but whether you were thoughtful and professional in your communication. Specifically, I will ask about whether you clearly outlined goals (and nongoals) and how you kept them updated of your progress.
  • Individual evaluation (30/100%)

    • I will ask you to write a short qualatative assessment of each of your group members. This will be a paragraph highlighting the strengths of each group member and an outline of what they brought to the project. I will also ask you about whether each member was generally “checked in” or not. I will then ask you to write a self-reflection containing the following:

      • One particular feature of the app that was yours
      • What you learned on the project
      • Issues that came up as you went about the project
      • How you tackled those issues
      • How you interacted with other group members when contentious or challenging issues arose
      • Things you think you struggled at during the project
      • Things you think you did particularly well during the project
    • I will then give you a grade between 0 and 30% based on (at least) the following factors

      • Were you generally checked in and an active member of your group
      • Did you write a decent amount of code for the project. Not all code is equal, and in particular, I won’t grade students lower or higher just because one wrote more code than the other. But I want to see that everyone contributed something serious.

In particular, I ask the following of you:

  • Every group member should have at least one feature that is “theirs” to implement.

  • Do not “cover” for a groupmate that is doing nothing. It is totally okay if one student is less experienced than another: the goal is that every student will bring something different and unique to the group, and I natuarally expect some students will do more coding than others. But every student needs to touch and work on the code, since if they don’t do that, they won’t learn how to do development.

  • Play the long game. You don’t have to put in 20 hours of work on the app every week.

  • Don’t be too stressed out: if you’re overwhelmed with what is going on, let me know and we can talk about it.

  • Try not to let animosity fester. We all communicate differently, and what you see as a groupmate totally lagging on the project might be a communication failure. Interact with your groupmates assuming the best of them.

  • Please bring issues to me early. Particularly, if your project mentor / sponsor is asking for something unrealistic, please let me know, I will advocate for you to make sure it’s a project you can achieve.

Weekly updates

You should send me a weekly update email, every Tuesday night, with the following information:

  • What each group member did. This can even be “nothing, but I plan to do a lot very soon.” It should be an honest reflection.

  • What you did: the commits, tests, etc.. Be specific.

  • What you plan to do: what code you intend to write next.

  • Things you’re struggling with, and how you plan to address it.

  • Generally, how you’re feeling about the project.