2022-2023 Senior Seminar
#senior-seminarThis website is the source of truth for class this semester. Materials will be linked and distributed from this website. There is no Canvas website. Announcements and course communication will be done through Slack, and I expect that you are actively participating in the Slack channel.
| Day | Topic and Assignments |
|---|---|
| Thu Jan 12 | Welcome – class format; standup signup |
| Mon Jan 16 | No Class – MLK Jr. Day |
| Tue Jan 31–Thu Feb 2 | Q1 Presentations |
| Tue Feb 28–Thu Mar 2 | Q2 Presentations |
| Fri Mar 3 | Midterm reflections due |
| Mon Mar 13–Fri Mar 17 | Spring Break |
| Tue Apr 4–Thu Mar 6 | Q3 Presentations |
| Thu Apr 6–7 | Easter recess |
| Fri Apr 28 | Rhodes Symposium – Final Presentations |
| TBD | Final exam and final reflections due |
You have 15 weeks to complete the project that you designed in Fall ‘22. We will break up these 15 weeks into four quarters. Each quarter, your team will be responsible for presenting and assessing progress on intermediate engineering milestones.
In between these quarterly checkpoints, your team will have weekly standups and status updates with me. This will be a dedicated time during our class meeting hours where your entire team will meet with me.
Your team will use GitHub issues and projects to track and monitor status of individual action items that are part of larger milestones.
All of these processes are outlined below.
At the end of each quarter, your team will present your current status and assessment of the milestones that you had planned for the quarter. You will include a presentation of your milestones for the following quarter.
The milestones that you assess/present should be large pieces of functionality for your project. For example, a milestone might be to implement the registration authentication flow for your application, implement a library to detect and report the presence of a BLE beacon, build out integration tests for a large piece of functionality, implement a persistence layer, etc.
Your milestones should be appropriately large that you believe that 1–2 people could complete them in four weeks (60–120 engineer-hours).
Each milestone should be assigned a priority between 0 and 4:
| Priority | Meaning |
|---|---|
| P0 | This must be complete by the end of the quarter, otherwise the project is at risk of failure |
| P1 | This should be complete by the end of the quarter, otherwise the project is at risk of falling behind or culling features |
| P2 | This would like to be completed by the end of the quarter, but can slip to the next quarter (and will have an escalated priority) |
| P3 | This is work that is nice to have, but not necessary; it may rise to P2 in the next quarter, or it may be considered fit-and-finish (e.g., UI/UX polishing). |
| P4 | This is exploratory or unnecessary to the core functionality. |
Your team should include at least one P0 milestone per team member or pair of team members. As we progress through the semester, I would assume that you are able to increase the amount of nice-to-have work in your backlog. Your riskiest features and questions should be reflected in your P0–P1 milestones.
Each milestone must have an owner: a person responsible for driving that milestone to completion.
The number and size of your milestones should be ambitious: you should plan for more work than you believe your team can actually complete. This allows for your team to have a roadmap if you are ahead on goals and also allows your team to cull low-priority milestones and put your effort behind your highest priority milestones.
A good goal for completion of milestones should be 80% and you should consider meeting 80% of your milestones to be on-target/making sufficient progress to complete the project.
You should plan your Q1 milestones before Tues Jan 17. You will report these out in the Slack channel and discuss them with me in our standup.
For subsequent quarters, we will meet and discuss your progress as well as your milestones for next quarter.
Your presentation should include an assessment of how complete each milestone is (as a percentage) and an overall assessment of what percent of milestones you completed.
You should also include a presentation of your milestones for the subsequent quarter.
These presentations should be ~20 minutes (leaving us time for short standups/checkins during these weeks).
Presentation schedules will be assigned as we progress through the semester.
Each team will meet with me for a weekly standup. In our standup, each team member will report out:
Your standup time will be scheduled during our class time. Your team should (read: must) meet outside of our scheduled meeting time for your own individual meetings and standups.
We will not have a strictly-enforced process model for your teams. However, each team must–at the very least–track their work using issues on your GitHub repository.
If your team wants to follow a more rigid agile process, you must use GitHub for your workflow (i.e., you must use GitHub projects instead of other tools, like Trello).
Do not use other tools (like Jira, etc.), even though you may be familiar with them. I would like for us to have a standardized set of tools that we are using for projects and project management, and GitHub’s built-in tools are more than enough for the scope of our projects in their current state.
You’ll use GitHub issues to track work. Make sure that you read GitHub’s guide on how to track work with issues. You’ll want to ensure that your team reads and understands how to achieve common project management tasks using GitHub; this document describes how to use the features that GitHub provides for project management.
Issues must be created for each milestone. The issue should be assigned to the issue owner, and the owner should use the issue to track their progress on the milestone. This means that the issue should be updated at least on a weekly basis, and include discussion of blocking issues, challenges, and decisions that the owner encounters as they arise.
You should update an issue, for example, with the result of discussions that your team has about direction or decisions, for every PR that you make to the repository, etc.
Note that an update to an issue is not changing the issue description, or editing existing text: it is including status updates, decisions, etc. in the form of adding comments on the issue. You should never delete any text or comments on an issue.
Issues should be created for each milestone, but it is expected that you will sometimes want to break large milestones down into intermediate steps. For example, a milestone might be something like:
An issue should contain, at the very least, a description of what the desired outcome should be. This can be in the form of writing, images and mockups, tests that should pass, or any number of things.
Note that this description is the what – not the how. The how is the actions that you take to achieve the outcome, and these actions can be documented in the form of updates on an issue.
Take a look through the open and resolved issues for project like Signal, for example. You’ll see that bug reports or performance issues may discuss particular technical details (i.e., the how), but feature requests stick to the what.
Some milestones will be comprised of a large set of sub-tasks. For example, here’s a few things that some task like this might include:
Each of these tasks is large enough that it warrants tracking its progress. When you encounter tasks like these, create them as individual issues.
You should use GitHub’s ability to track dependencies between issues to manage related issues (called task lists). This allows for you to have a clear picture of all the work that must be done for a particular milestone, and provides you with individual tasks that must be done.
All code must be checked in to your GitHub repository (or repositories). All
checked-in code must go through peer review in the form of a review on a pull
request (by extension, you may not commit directly to main).
When you submit PRs, use descriptions and titles that reference the issues they address. Follow the GitHub instructions for how to link issues and PRs. See the additional documentation for how to write on GitHub and cross reference issues and code.
You will be assessed on your participation in your team’s project, participation in the class activities, and the completion of your team project.
Your team contract outlines the standards that you have agreed to hold each other to, and you are expected to adhere to that contract.
Violations of the contract (e.g., not participating in meetings or your team’s process) will affect your grade in the course.
You will be required to present your work at Rhodes Symposium. In Q4, we will discuss the process for this.
You will also be required to write a team and individual reflection on your progress, both at the midterm as well as at the conclusion of the semester. As we approach the midterm, I will post the format for these reflections.
All of these elements will be used as components in the calculation of your final grade.