[Individual] Expectations on Enhancements

• You are expected to enhance the product in some way(s). User-visible enhancements are preferred, but it is not a strict requirement. Some examples:

• The enhancement(s) should fit with the rest of the software (and the target user profile) and should have the consent of the team members. You will lose marks if you go 'rogue' and add things that don't fit with the product.

• How much code to write? The project grade depends on the value you added, as perceived by evaluators (i.e., team members, peer evaluators, and tutors) as well as other factors such as the quality of the code. As such, there is no strong correlation between the LoC and the grade. For instance, in a recent semester, a student who wrote 500 LoC of functional code (i.e., excluding test code and documentation) was able to reach top 20% (in terms of project marks), another who wrote 900 LoC reached the top 10%, while another who wrote more than 5000 LoC ended up in the bottom 10%. Also see the the percentiles of functional LoC written by that batch of students, given below:

  Percentile	25	50	75
  LoC	~1000	~1500	~2500

[Individual] Expectations on Documentation

• You are expected to write user documentation and developer documentation for your features.
• The objective is to showcase your ability to write the two types of documentation. If the documentation for your features is not enough to meet that objective, or does not reach the following minimal requirement, you can make up the shortfall by documenting 'proposed' features and alternative designs/implementations.
  • Contribution to the user guide: 1 page
  • Contribution to the developer guide: 3 pages
• You are expected to showcase your ability to use the various UML diagrams (at least 2 types). As mentioned in the previous point, if the documentation of your features doesn't give you enough opportunities to do so e.g., your features only required minor updates to existing diagrams, you are expected to create those opportunities yourself by documenting proposed features or alternative designs. Evaluators will not be able to give you marks unless there is sufficient evidence of your documentation skills.
• You are required to update the entire UG and DG to match your product. However, there is no need to update other documents such as tutorials that are AB3 specific.

[Individual] Expectations on Testing

[Individual] Expectations on Teamwork

Team-tasks are the tasks that someone in the team has to do. Marks allocated to team-tasks will be divided among team members based on how much each member contributed to those tasks.

Here is a non-exhaustive list of team-tasks:

1. Necessary general code enhancements e.g.,
   1. Work related to renaming the product
   2. Work related to changing the product icon
   3. Morphing the product into a different product
2. Setting up the GitHub, Travis, AppVeyor, etc.
3. Maintaining the issue tracker
4. Release management
5. Updating user/developer docs that are not specific to a feature e.g. documenting the target user profile
6. Incorporating more useful tools/libraries/frameworks into the product or the project workflow (e.g. automate more aspects of the project workflow using a GitHub plugin)

Roles indicate aspects you are in charge of and responsible for. E.g., if you are in charge of documentation, you are the person who should allocate which parts of the documentation is to be done by who, ensure the document is in right format, ensure consistency etc.

This is a non-exhaustive list; you may define additional roles.

• Team lead: Responsible for overall project coordination.
• Documentation (short for ‘in charge of documentation’): Responsible for the quality of various project documents.
• Testing: Ensures the testing of the project is done properly and on time.
• Code quality: Looks after code quality, ensures adherence to coding standards, etc.
• Deliverables and deadlines: Ensure project deliverables are done on time and in the right format.
• Integration: In charge of versioning of the code, maintaining the code repository, integrating various parts of the software to create a whole.
• Scheduling and tracking: In charge of defining, assigning, and tracking project tasks.
• [Tool ABC] expert: e.g. Intellij expert, Git expert, etc. Helps other team member with matters related to the specific tool.
• In charge of[Component XYZ]: e.g. In charge of Model, UI, Storage, etc. If you are in charge of a component, you are expected to know that component well, and review changes done to that component in v1.3-v1.4.

Please make sure each of the important roles are assigned to one person in the team. It is OK to have a 'backup' for each role, but for each aspect there should be one person who is unequivocally the person responsible for it.

Team Expectations

1. Preserve product integrity: i.e. ensure,
   1. features fit together to form a cohesive product,
   2. documentation follows a consistent style and presents a cohesive picture to the reader, and
   3. final project demo presents a cohesive picture to the audience.
2. Maintain product quality: i.e. prevent breaking other parts of the product as it evolves. Note that bugs local to a specific feature will be counted against the author of that feature. However, if a new enhancement breaks the entire product, the whole team will have to share the penalty.
3. Manage the project: i.e. ensure workflow, code maintenance, integration, releases, etc. are done smoothly.

After completing v1.1, you can reduce process rigor to suit your team's pace. Here are some examples:

• Reduce automated tests: Automated tests have benefits, but they can be a pain to write/maintain; GUI tests are especially hard to maintain because their behavior can sometimes depend on things such as the OS, resolution etc.
  It is OK to get rid of some of the troublesome tests and rely more on manual testing instead. The less automated tests you have, the higher the risk of regressions; but it may be an acceptable trade-off under the circumstances if tests are slowing you down too much.
  There is no direct penalty for removing tests. Also note our expectation on test code.

• Reduce automated checks: You can also reduce the rigor of checkstyle checks to expedite PR processing.

• Switch to a lighter workflow: While forking workflow is the safest, it is also rather heavy. You an 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.

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.

• There is no requirement for a minimum coverage level. Note that in a production environment you are often required to have at least 90% of the code covered by tests. In this project, it can be less. The less coverage you have, the higher the risk of regression bugs, which will cost marks if not fixed before the final submission.
• You must write some tests so that we can evaluate your ability to write tests.
• How much of each type of testing should you do? We expect you to decide. You learned different types of testing and what they try to achieve. Based on that, you should decide how much of each type is required. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.

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 (or type.Chore) : 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.VeryLow : A flaw that is purely cosmetic and does not affect usage e.g., a typo/spacing/layout/color/font issues in the docs or the UI that doesn't affect usage.
• 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

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.