iP:
tP: v1.1
If you wish to cite the iP in your resume, you can do more to make it look more impressive to a potential employer. These improvements are not considered for grading and can be done after the semester is over. Some ideas:
On a somewhat related note, you can also create similar product websites for your other projects (projects from other courses, pet projects).
What's happening this week:
This week, we do the first tP iteration: v1.1.
Each tP iteration focuses on a specific learning outcome, a corresponding product goal, and a strategy that we'll use to achieve both. The ones for this tP iteration (i.e., v1.1) are given below:
v1.1
Aim to do 'just enough': Note how the Product goal (together with the Strategy) is simply a means to achieve the Learning outcome. Unlike in a real SE project, the product in the tP exists only to help you achieve the learning outcome. Hence, aim to do 'just enough' work on the product to achieve the intended learning outcome of the iteration (e.g., don't make features bigger than necessary) so that the tP doesn't add to your workload more than necessary.
We consider this iteration a 'practice' iteration. Reason: As this is the first time your team is working on this codebase, we first focus on learning the workflow that you need to follow as a team. In this practice iteration, we limit ourselves to some document updates only (to minimize the risk of breaking the codebase).
Specifically, we start with a workflow practice session (in task 1), and proceed to do some further documentation updates in tasks 2 and 3.
Things to note:
COMMON MISTAKE: Not following the convention for Git commit message subject.
Caution: This is very hard to rectify later, after the PR containing the commits have been merged. Reason: While Git allows editing past commits, doing so changes their timestamp, which affects your weekly code contribution stats (which are factored into evaluating the consistency of your coding work over the project duration).
COMMON MISTAKE: Forgetting to do each PR from a separate branch (i.e., send PR from the master
branch) of your fork. This error means your PR will not be considered as following the forking workflow correctly.
Start using Git via the CLI
If you have been using Sourcetree (or other GUI) for Git before, we strongly recommend that you move towards using the CLI to perform Git tasks in the second half of the semester. Doing so will strengthen your Git knowledge (because CLI takes you closer to what's actually happening, while GUIs might hide such details).
But you can continue to use your favorite Git GUI for a more 'visual' view of your repo, side-by-side with the CLI e.g., from Sourcetree, you can open a gitbash terminal, run the command in that terminal, and see the result in the GUI.
Task: Do a workflow 'practice' session, to get all team members familiarized with the workflow you need to follow in the tP.
Why?: The ability to modify a team-owned codebase in parallel is an important learning outcome of this course. Following a suitable workflow is critical for achieving that. This practice iteration is for you to get used to the workflow that you need to follow in the tP.
Strongly recommended to do this as a team activity (preferably F2F, or else connected via Zoom/MST). That will help you proceed faster (e.g., a PR can be merged soon after it has been created) and will also make it easy for you to help each other w.r.t. to the workflow matters.
Steps:
v1.1
and set an appropriate deadline (i.e., same as, or earlier than, the iteration deadline)Add Jake's photo
.v1.1
to indicate this task is due in v1.1
, as given in the panel below.docs/images/github_username_in_lower_case.png
JohnDoe123
-> docs/images/johndoe123.png
not docs/images/JohnDoe123.png
..png
anyway.Updating the AboutUs page:
This page (in the /docs
folder) is used for course admin purposes. Please follow the format closely or else our scripts will not be able to give credit for your work. Similarly, do not split the given .md
files further into multiple files, as our grading script will check the given files only.
tP Briefing video (Part 2a -- v1.1, Workflow)
has a section on how to resolve conflicts in PRs.Now that you have learned the tP workflow, you can proceed to updating a few more tP documents, as per tasks A and B below, following the same workflow (optional to do parallel PRs though).
Recommended procedure for updating docs:
Guidance on using documentation tools (e.g., How to preview changes locally before committing/pushing) can be found in the relevant section of the Developer Guide of your team project website that you set up earlier. Given below is a shortcut, for your convenience:
A: Update README page to match your project:
docs/images/Ui.png
so that it can be downloaded by our scripts. Limit the file to contain one screenshot/mockup only and ensure the new image is roughly the same height x width
proportions as the original one. Reason: when we compile these images from all teams into one page (example), yours should not look out of place.This project is based on the AddressBook-Level3 project created by the [SE-EDU initiative](https://se-education.org).
If you did the above updates correctly, your UI mock up and profile photos should appear in your project website and this Project List Page.
B: Also update site-wide settings, as necessary:
You need to update the AB-3
in the top navigation bar of your project website (it's in docs\_config.yml
and docs/_sass/minima/_base.scss
if using Jekyll; in docs\_markbind\layouts\default.md
if using MarkBind).
More info on updating site-wide settings such as the above:
Add the following to the DG, based on your project notes from the previous weeks. No need to update other sections, for now.
Some examples of these can be found in the AB3 Developer Guide.
The above DG sections should cover the full requirements of the product, some of which might not even get implemented by the end of this semester i.e., do not limit to just the requirements you intend to implement in the next iteration. Reason: All identified requirements need to be documented for future reference.
Furthermore, these sections will be graded at the final project evaluation, and any bugs in the content can cost you marks at that point. The panel below gives some relevant DG bug examples you can lookout for:
v1.2
).