CS2103/T - Admin: tP Week 8: First feature increment → v1.2

Divide MVP features among members
/ [Optional] Rename packages/classes
Add the first functionality increment Thu, Oct 10th 23:59

Intro to tP Week 8

What's happening this week:

Having practiced the workflow in the previous iteration, this week's iteration v1.2 adds the first functional code changes.

v1.2

Learning outcome: Able to update functional code while working in parallel.
Product goal: Take the first step towards an MVP by delivering at least some functionality changes.
Strategy: Define the smallest possible MVP (simplest versions of must-have features only). Each member tries to merge at least one PR that moves the product towards that MVP.

The breadth-first iterative approach requires each intermediate version to be a working version. However, to make things a bit easier for us (as we are only getting started with the project), we will not be releasing any new product version at the end of this iteration. This means you have the freedom to create PRs for small code changes, without the pressure to implement a feature end-to-end within one PR (or even within this iteration).

Things to note:

Read our reuse policy (in Admin: Appendix B), in particular, how to give credit when you reuse code from the Internet or classmates:

Note the individual and team expectations of the tP, if you haven't done so already.

COMMON MISTAKE: Not following the required phrasing style for the first sentence of Java method header comments.

1 Divide MVP features among members

Re-confirm MVP feature design. Recall that you decided on features to include in the MVP version of the product. Revisit that design. Ensure the following (you may refine the MVP feature design if necessary).
- It consists of not only
  the most essential features of the target product, but also,
  the simplest implementation of those features (e.g., when adding a new feature to track birthdays of contacts, the simplest implementation of it could be simply adding a new text field for the contact).
- It will still be a working product (i.e., it can be used)
  Reason: As we are following the breadth-first iterative approach, each intermediate version should be a working product.
Divide the features among the team members i.e., who will be implementing which feature.
- Reminder: We recommend that the work to be divided primarily based on features/enhancements rather than components.

2 / [Optional] Rename packages/classes

If you wish to rename AB3 packages/classes to fit your product, this is the best time to do so (i.e., before starting any functionality changes), as such changes cause widespread changes to the codebase, causing many merge conflicts with any other ongoing PRs.
Renaming packages/classes is optional. It is fine to keep the existing ones. But if you decide to rename them, do it quickly, and remember to follow the workflow you practiced in the previous week.

3 Add the first functionality increment Thu, Oct 10th 23:59

Each member is expected to in each .
Reason: As each iteration focuses on a different learning outcome, it is better for you to take part in each of them fully.

FAQ Will I lose marks if I couldn't merge any PRs in an iteration?

Prefer smaller PRs.
Reason: The ability to divide work into small yet meaningful PRs is another intended learning outcome.

For example, suppose you are asked to implement a feature F in the current iteration. Instead of creating one big PR for it, you can start with a smaller PR that implements a very VERY simple version of F, followed by a few more PRs that improve F incrementally.
Side reading : [blog post] Small Pull Requests: 6 reasons why they are the best choice.

Steps:

S1.
Select a code change to implement, as follows:
- Consider the feature that you have been assigned to implement for the upcoming MVP version of the product (which will be released by the iteration v1.3, not by the current iteration v1.2).
- Pick a small code change that you'll need to do to implement that feature. This is a small code change contributing towards the feature, not the entire feature itself. Examples: add parser support for a new command word, add a field to the person class.
S2.
Implement that code change while following the workflow that you practiced in the previous week. A summary of the steps:
- Create an issue for it. Assign it to yourself. Assign it to milestone v1.2.
- Create a PR from a separate branch in your fork. Assign it to v1.2.
- Get the PR reviewed.
- Get the PR merged. Close the corresponding issue.
Continue to implement more code changes (i.e., repeat S1 and S2) to implement more code changes that move you towards your MVP feature(s). You can even create parallel PRs, when implementing code changes with no/low dependency between them.
S4.
Wrap up the milestone When the iteration period is over, do the following:
- Move any pending issues/PRs to the next milestone (i.e., v1.3). As we did not plan to release a product version at the end of this iteration, we can freely move any pending work to the next iteration.
- Close the milestone.

FAQ Do we have to update tests when we update functional code?

FAQ Do we need to update user/developer guides to match code changes?

End of tP Week 8

Shocked by iP to tP transition? Around this time you will realize how the speed you can implement things in the tP is significantly slower compared to the iP. As discouraging as this might feel, there are several ways this can contribute towards the learning outcomes of this course, and it is not expected to affect your tP grade either.