- Make the code more defensive
- Deliver v1.0 midnight before the tutorial
- Do an informal demo of v1.0 before the tutorial
1 Make the code more defensive
- Improve the defensiveness of the code: We recommend you add assertions, exceptions, and logging to your code.
Remember to enable assertions in your,- IDEA run configurations -- if your Intellij is set not to use Gradle when running the project)
- the
build.gradlefile -- if you use Gradle to run the project, or if your Intellij is using Gradle to run the project
2 Deliver v1.0 midnight before the tutorial
- When the v1.0 is ready, do a release on GitHub. Remember to upload the jar file as well.
- Wrap up the milestone on GitHub.
Admin Appendix E(extract): Project schedule tracking
tP Project Schedule Tracking
In general, use the issue tracker (Milestones, Issues, PRs, Tags, Releases, and Labels) for assigning, scheduling, and tracking all noteworthy project tasks, including user stories. Update the issue tracker regularly to reflect the current status of the project. You can also use GitHub's Projects feature to manage the project, but keep it linked to the issue tracker as much as you can.
Using Issues:
- Record each of the user stories you plan to deliver as an issue in the issue tracker. e.g.,
You can break the user story into issue subject and description in this way:
| title | As a user I can add a deadline |
|---|---|
| Description | ... so that I can keep track of my deadlines |
Alternatively, you can put the entire user story in the description.
| title | Add deadline |
|---|---|
| Description | As a user I can so that I can keep track of my deadlines |
In both cases, apply the type.Story label.
-
Assign the
type.*andpriority.*labels to those issues. -
Formalize the project plan by assigning relevant issues to the corresponding milestone.
-
Define project tasks as issues. When you start implementing a user story (or a feature), break it down to smaller tasks if necessary. Define reasonable sized, standalone tasks. Create issues for each of those tasks so that they can be tracked.
-
A typical task should be small enough for one person to do in a few hours. eg.,
- Bad (reasons: not a one-person task, not small enough):
Write the Developer Guide - Good:
Update class diagram in the Developer Guide for v2.1
- Bad (reasons: not a one-person task, not small enough):
-
There is no need to break things into VERY small tasks. Keep them as big as possible, but they should be no bigger than what you are going to assign a single person to do within a week. eg.,
- Bad:
Implementing parser(reason: too big). - Good:
Implementing parser support for adding of floating tasks
- Bad:
-
Do not track things taken for granted. e.g.,
push code to reposhould not be a task to track. In the example given under the previous point, it is taken for granted that the owner will also (a) test the code and (b) push to the repo when it is ready. Those two need not be tracked as separate tasks. -
Write a descriptive title for the issue. e.g.
Add support for the 'undo' command to the parser- Omit redundant details. In some cases, the issue title is enough to describe the task. In that case, no need to repeat it in the issue description. There is no need for well-crafted and detailed descriptions for tasks. A minimal description is enough. Similarly, labels such as
prioritycan be omitted if you think they don't help you.
- Omit redundant details. In some cases, the issue title is enough to describe the task. In that case, no need to repeat it in the issue description. There is no need for well-crafted and detailed descriptions for tasks. A minimal description is enough. Similarly, labels such as
-
-
Assign tasks (i.e., issues) to the corresponding team members using the
assigneesfield. Normally, there should be some ongoing tasks and some pending tasks against each team member at any point.
Using Milestones:
Given below are the conditions to satisfy for a milestone to be considered properly managed:
Planning a Milestone (to do within the first week of the iteration):
-
Issues assigned to the milestone, team members assigned to issues: Used GitHub milestones to indicate which issues are to be handled for which milestone by assigning issues to suitable milestones. Ensured issues are assigned to team members. Note that you can change the milestone plan along the way as necessary.
-
Deadline set for the milestones (in the GitHub milestone). Your internal milestones can be set earlier than the deadlines we have set, to give you a buffer.
Wrapping up a Milestone:
-
A working product tagged with the correct tag (e.g.
v2.0) and is pushed to the main repo or a product release done on GitHub (example). -
CI passing for the version tagged/released.
-
Milestone updated to match the product i.e. all issues completed and PRs merged for the milestone should be assigned to the milestone. Incomplete issues/PRs should be moved to a future milestone.
-
Milestone closed.
3 Do an informal demo of v1.0 before the tutorial
- As we don't have in-class tutorials this semester, do the following in lieu of a live demo:
[one member] Run your app using the latest released versionv1.0. Take screenshots of each available feature in action. Add those screenshots to your collaborative project notes document with an appropriate heading e.g.,v1.0 features demo. Alternatively, you can screen-record a demo, upload it to somewhere, and post the link in the project notes document.