This site is from a past semester! The current version is here.

Week 8 [Oct 7]

Project Milestone: mid-v1.2

Attempt to do global-impact changes to the code base. Adjust project schedule/rigor as needed, start proper milestone management.

Project Management:

💡 You are free to adjust process rigor and project plan at any future time in the project, starting from v1.2.
If you are not sure if a certain adjustment is allowed, you can check with the lecturer first.

Adjust process rigor to suit your team's pace:
- Switch to a lighter workflow: While forking workflow is the safest, it can be heavy. You can switch to a simpler workflow if the forking workflow is slowing you down.
  Refer the textbook to find more about alternative workflows: branching workflow, centralized workflow.
  However, we still recommend that you use PR reviews, at least for PRs affecting others' features.
- Reduce automated checks: You can also reduce the rigor of checkstyle checks to expedite PR processing.
- You can also increase the rigor/safety of your workflow in the following ways:
  - Use GitHub's Protected Branches feature to protect your master branch against rogue PRs.
Adjust project plan if necessary. By now you will have a some idea about the code base and the product that you envisoned. You can revisit the feature release plan and adjust it if necessary.
(If you haven't already done) Set up the issue tracker:

Relevant: [Admin Appendix E(extract): Setting up the issue tracker ]

Issue tracker setup

We recommend you configure the issue tracker of the main repo as follows:

Delete existing labels and add the following labels.
💡 Issue type labels are useful from the beginning of the project. The other labels are needed only when you start implementing the features.

Issue type labels:

type.Epic : A big feature which can be broken down into smaller stories e.g. search
type.Story : A user story
type.Enhancement: An enhancement to an existing story
type.Task : Something that needs to be done, but not a story, bug, or an epic. e.g. Move testing code into a new folder)
type.Bug : A bug

Status labels:

status.Ongoing : The issue is currently being worked on. note: remove this label before closing an issue.

Priority labels:

priority.High : Must do
priority.Medium : Nice to have
priority.Low : Unlikely to do

Bug Severity labels:

severity.Low : A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only.
severity.Medium : A flaw that causes occasional inconvenience to some users but they can continue to use the product.
severity.High : A flaw that affects most users and causes major problems for users. i.e., makes the product almost unusable for most users.

Create following milestones : v1.0, v1.1, v1.2, v1.3, v1.4,
You may configure other project settings as you wish. e.g. more labels, more milestones

(If you haven't already done) Start proper schedule tracking and milestone management:

Relevant: [Admin Appendix E(extract): Project schedule tracking ]

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:

During the initial stages (latest by the start of v1.2):

Record each of the user stories you plan to deliver as an issue in the issue tracker. e.g. Title: As a user I can add a deadline
Description: ... so that I can keep track of my deadlines
Assign the type.* and priority.* labels to those issues.
Formalize the project plan by assigning relevant issues to the corresponding milestone.

From milestone v1.2:

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.e.g.
- A typical task should be able to done by one person, in a few hours.
  - Bad (reasons: not a one-person task, not small enough): Write the Developer Guide
  - Good: Update class diagram in the Developer Guide for v1.4
- 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
- Do not track things taken for granted. e.g., push code to repo should 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 priority can be omitted if you think they don't help you.
Assign tasks (i.e., issues) to the corresponding team members using the assignees field. Normally, there should be some ongoing tasks and some pending tasks against each team member at any point.
Optionally, you can use status.ongoing label to indicate issues currently ongoing.

Using Milestones:

We recommend you do proper milestone management starting from v1.2. Given below are the conditions to satisfy for a milestone to be considered properly managed:

Planning a Milestone:

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. Also make sure those 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. v1.2) and is pushed to the main repo
or a product release done on GitHub. A product release is optional for v1.2 but required from from v1.3. Click here to see an example release.
All tests passing on Travis 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.
If necessary, future milestones are revised based on what you experienced in the current milestone e.g. if you could not finish all issues assigned to the current milestone, it is a sign that you overestimated how much you can do in a week, which means you might want to reduce the issues assigned to future milestones to match that observation.

Product:

From v1.2 onwards each member is expected to contribute some code to each milestone, preferably each week; only merged code is considered as contributions (Reason) .
If an enhancement is too big to complete in one milestone, try to deliver it in smaller incremental steps e.g. deliver a basic version of the enhancement first.