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

Week 11 [Oct 28]

Project

This week, you need to create a a release for your product, with a JAR.
Ensure that the product is user testable.
Update the documents to reflect the state the product.
- Mark irrelevant sections as coming in v2.0.

User testing session

Ensure that you have accepted the invitation to join the GitHub org used by the module. Go to https://github.com/nusCS2113-AY1920S1 to accept the invitation.
- If you cannot find the invitation, post in our forum.

Ensure you have access to a computer that is able to run module projects e.g. has the right Java version.

Download the latest CATcher and ensure you can run it on your computer.

Create a public repo in your GitHub account with the following name:
- PE Dry Run: ped
- PE: pe
Enable its issue tracker and add the following labels to it (the label names should be precisely as given).

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.

Bug Type Labels:

type.FeatureFlaw: some functionality missing from a feature delivered in v1.4 in a way that the feature becomes less useful to the intended target user for normal usage. i.e., the feature is not 'complete'. In other words, an acceptance testing bug that falls within the scope of v1.4 features. These issues are counted against the 'depth and completeness' of the feature.
type.FunctionalityBug: the bug is a flaw in how the product works.
type.DocTypo: A minor spelling/grammar error in the documentation. Does not affect the user.
type.DocumentationBug: A flaw in the documentation that can potentially affect the user e.g., a missing step, a wrong instruction

Have a good screen grab tool with annotation features so that you can quickly take a screenshot of a bug, annotate it, and post in the issue tracker.
- 💡 You can use Ctrl+V to paste a picture from the clipboard into a text box in GitHub issue tracker.
Download the product to be tested after you have been notified of which team you have been allocated to test.
- Do this before you come to the testing session to minimize the network clogging due to large number of downloads happening at once.
Charge your computer before coming to the PE session. The testing venue (lecture theatre) does not have enough charging points.

Demo during tutorial

Two members do a timed demo in the tutorial this week. (Come prepared for demo!)

(Mock) Submissions this week

Submit the following documents on LumiNUS.
- Ensure that the file names are accurate. While there is no penalty now for non-compliance, you will lose marks for making similar mistakes in the final submission.
The submission folder Project submission v1.3 will be open from Oct 29, 2019 00:00 am to Oct 31, 2019 11:59 pm

Team/Individual Item	Name format	Upload to
User Guide	`[TEAM_ID]-[product Name]-UG.pdf` e.g.`[AY1920S1-CS2113T-F10-3]-ProDuke-UG.pdf`	LumiNUS
Developer Guide	`[TEAM_ID]-[product Name]-DG.pdf` e.g. `[AY1920S1-CS2113T-F10-3]-ProDuke-DG.pd`f	LumiNUS
Project Portfolio Page	`[TEAM_ID]-[Your Name]PPP.pdf` e.g.`[AY1920S1-CS2113T-F10-3][John Doe]PPP.pdf`	LumiNUS

FAQ for Reposense

My contributions are not detected in the reposense report, why?
1. Check:
  1. Have you set the user.name to your GitHub user name that you provided in the pre-module survey?
  2. Have you used different git user name while doing the work? Run git log command on the command line/terminal and look for the Author field.
2. If the above are correct, you should provide the additional names appearing on git log to the lecturer.
I have done everything given in 1, but I still can't see my contributions. How to resolve?
1. Use @@author tags to identify your code contribution in the source files.
2. Follow the instructions given in the reposense documentation for this
3. Specifically, don't put @@author tags inside Javadoc comments, it should be placed before the Javadoc comments.
I did 1 & 2, however, I cannot still see my contributions. Help!!
1. Usually, most cases will be taken care of by 1 and 2 above.
2. In case your contributions are still not detected, please post the issue on this forum, we will get the reposense team to take a look.
How frequently is the reposense report generated?
1. Reposense is configured to run the report everyday.
My friend and I worked on a piece of code together, but only my friend committed. Now how?
1. Use @@author tags to indicate chunks of the file that is your contribution. Arrive at a consensus with your friend/teammate before claiming part of the code as yours.
What is considered good contribution?
1. Speaking from code-quality evaluation perspective, you need to have contiguous code chunks in your contribution (e.g., some full classes, some significantly long full methods).
2. If the code is fragmented (e.g., you only added one additional field to a class, and the entire code has fragmented one-two lines that work with the additional field you creates) it becomes hard to grade the code quality.