Find the PR you have been allocated to discuss (given below). If the allocated PR is not available or suitable, you can choose the fallback option, and failing that, any random PR.
PR allocation
10 minutes Find potential abstraction problems: Go through the code in the dif view (i.e., the Files changed tab), and and find potential abstraction problems (weak SLAP, arrow-head style code, too-long methods, too-deep nesting)
To identify long methods or deep nesting, zoom out and scroll through the entire PR code to do a visual inspection (no need to read the code line-by-line). After visually locating a method that looks too long/deep, have a closer look to see it can be improved by using better abstraction.If you are unsure about a case, you can also rope the tutor in to the discussion.
10 minutes Discussion: The tutor will lead a short discussion to go through the problematic code you found.
After the tutorial, you can apply the insights gained from this activity to improve the code quality of your own iP, if necessary.
Admin tP → Week 5 → Choose user stories for v1.2
Intuitively, you might think the right thing to do is to decide what features will be in v1.4 and then plan the intermediate versions based on that. But that's not what we are going to do.
Why? Given the difficulty of reliably estimating the effort each feature will need, any such long-range plan is likely to be inaccurate.
Instead, what we will do is to assume the current iteration is the last iteration, plan that iteration to deliver the product (based on available time), and try to follow that plan as best as we can. After the iteration is over, we plan the next iteration as if it's the last iteration. But that time, you can factor in the experience from the previous iteration to do a better job of planning.
How is that better?
The goal of this activity is to come up with the smallest possible product that is still usable so that it can be implemented as v1.2, to be delivered at the end of the first project iteration. We try to make it small because you will have only two weeks to implement v1.2 and coding as a team is a lot harder than writing code alone.
Do not discuss features, UI, command format, or implementation details yet. That would be like putting the cart before the horse. At this stage we are simply trying to choose which user needs to fulfill first.
Suggested workflow:
Admin tP → week 6 → Conceptualize v1.2
Requirements → Specifying Requirements → Feature Lists →
Feature list: A list of features of a product grouped according to some criteria such as aspect, priority, order of delivery, etc.
A sample feature list from a simple Minesweeper game (only a brief description has been provided to save space):