Skip to content

submission.md

Latest commit

 

History

History
75 lines (50 loc) · 4.72 KB

submission.md

File metadata and controls

75 lines (50 loc) · 4.72 KB

Artifacts

Process

  • Link to task boards for SPRINT 1, SPRINT 2

  • Link to USER STORIES board (for any additional user stories)

  • Link to a record of standup meetings including burndown for each sprint. Something like this:

    Date/Time Type Points Remaining Total
    Jan 1 4pm In Person 40 60 100
    Jan 2 3:30 pm Skype 55 57 112
    Jan 3 10am In Person 70 42 112
    Jan 4 12pm Slack 90 22 112
    Jan 5 8pm In Person 110 2 112

    If you're not meeting in person, I would also expect that your project group would have an active slack channel.

  • Completed retrospective google form (one per group): https://docs.google.com/forms/d/e/1FAIpQLScqZPQtdVDa59zqL5IbCnhCKilzCNdqK9mKDif9Z2xZH_by8w/viewform?usp=sf_link

Product

  • A link to your final project rendered on GitHub pages
  • A "data" or "backend" folder containing original source data, transformation steps (or python script), and final data that your visualization consumes for each dataset
  • A completed final project technical reflection from each student (these will be graded individually): https://forms.gle/PK13tcjCNvtAZFE39

Submitting the Project

When you're ready to submit the project, please create a new github issue in your repository called "Ready for Review". In your team's slack channel, post a link to that issue and mention all members of the teachhing team to let them know your project is ready for final review. Please note that the projects are due by 11:59pm Monday Jan 19.

Section A only: Please post a short handoff memo in your team's internal channel containing all research + scripts + appropriate links from your project.

Please communicate with the teaching team if you think your team needs more time and won't be able to meet the originally set due date so that we know when to expect a submission.

Grading

Your project will be worth 40% of your grade, that will be divided as follows

  • 10% process
    • Sprint Review (1x, the "review" for sprint 2 is the grading process)
    • Scrum Boards (2x sprints, 1x user story backlog)
    • Burndown Charts (2x, 1 per sprint)
    • Collaboration on GitHub
  • 30% product
    • Frontend
      • Working software
        • well defined user stories
        • working software that meet the user needs
      • Narrative Structure / Coherence
      • Visualizations
      • Code organization/cleanliness
      • Demonstrate understanding or experimentation through code comments
    • Backend
      • Data transformation (scripted or documented)
      • Clean and organized

Availability

The teaching team will hold office hours all day Saturday and Sunday. Feel free to ping Asa anytime Monday. If people want in-person office hours that day, he's happy to hold them.

Course Evaluations

You should have received an email about the course evaluations. They are accessible through the canvas page for this class and are due by January 20. Your honest feedback will be particularly important both in helping us understand how to best iterate on the course as well as helping the Kennedy School better understand the role of technical education in the curriculum. Please take some time to thoughtfully fill out the course evaluation.

Final Note

Please feel free to reach out via slack or email (asahejpal@hks.harvard.edu & dhrumil_mehta@hks.harvard.edu) if you have any further questions, comments or concerns. We look forward to hearing from you in the future about how you've used the knowledge you picked up during this course.

We hope you all found the projects instructive and enjoyable. Diving into new technologies can be both disorienting and rewarding. Learning new programming skills is often a cyclical process of getting stuck and unstuck. It is not uncommon to get lost in rabbit-holes of debugging or reading about technologies in an attempt to unpack how exactly they work.

Learning how to learn programming by searching the web for relevant resources, reading technical discussions and forums, and testing out example code snippets, as well as leaning on other programmers and knowing who to call when you're stuck are themselves important skills: skills which many of you got a chance to explore in attempts to customize your visualizations (some of you even decided to customize the JavaScript to change the behavior of the visualizations, which was not at all required for the project so kudos to those who tried!).

We hope that the class can serve as a stepping stone if you chose to further study technology or programming. If you don't ever end up coding again, we hope that the exercise of doing hands-on coding work has given you a better understanding of and appreciation for important issues at the intersection of technology and policy. Best of luck and enjoy!