Development Guidelines

About

This page contains a set of guidelines and conventions for the entire development process. There may be additional points along the way.

Development Process

Below are some ideas, will finalize later:

• Everyone will make their own branch, and the pull request will be to the development branch. Duc is the only one touching the main branch.
• Require review before merging.
• The use of git rebase is required to avoid messing up the history.
• The git work process.
• Process of reporting issues.

Meetings

We conduct weekly sprint meetings with our TA. In every meeting, we answer some questions: What have we done last week? What is our plan for the next week? What are the blockers? We ask TA questions at the end of each meeting.

Based on specific situations, we might divide our team into smaller teams and conduct meetings for those teams. Usually, they are work sessions and do not have a meeting minute.

Git/GitHub Work Process

A normal development process will roughly follow these steps:

1. Obtain your issue number from the project page
2. From the develop branch, checkout to the new branch with the naming convention of issues/<your issue number>. For example, if your issue number is 16 then you need to check out a new branch with the name issues/16 from develop using git checkout -b issues/16
3. Implement your solution, make sure to commit often, with descriptive commit message. Preferably, address your commit message in the format "Added / Modified / Fixed <functionality, bugs> to <file name(s)>" and elaborate more in the description of the message
4. Make sure to continuously update your local develop branch using git pull, and merge that branch with the branch you are working on to ensure receiving the newest version of the code
5. Once you are happy with your implementation, push your branch to a new branch on GitHub, using git push origin <your branch name>
6. Create a pull request to the remote develop with the name of the PR matched the issue title
7. Give a brief description for the PR (see a template below for PR description)
8. Tag someone to review your code
9. The reviewer will have to pull the branch, run the code, test it, then request changes or approved by comment "LGTM!" to the PR
10. Merge and close your PR, notify the team about the merge
11. Move on to the next issue

Pull Request Template:

In this PR, I have:

• Done A
• Finished B
• Fixed C

Note:

• A only covered D
• B is only implemented using technology E

Conventions

To ensure code quality and avoid mass confusion, we have decided to adopt some code conventions. These are to be modified if the situation requires, but until then, all of us adhere to the following:

1. Order of Class/Interface Declarations:

• Class/Interface documentation comment (such as Javadoc)
• Class/Interface statement
• Class/Interface implementation comment (optional - if necessary)
• Class (static) variables. Order: public, protected, no access modifier, private.
• Instance variables. Order: public, protected, no access modifier, private.
• Constructors
• Methods (grouped by functionality rather than scope or accessibility)

2. Avoid the use of deprecated features.

3. Avoid lines longer than 80 characters.

Some of these conventions are taken from those introduced in CMPUT 301 document: Code Conventions (Schoepp).pdf

Understanding our Github

Github is the control center of our project, and we would like everyone, especially developers, to understand it in and out. Remember that status, type, label, and milestones are all used on issues and that we reference issues when those are brought up.

Status

Currently, we have 5 kinds of status. The name of each is self-explanatory:

• Todo
• In progress
• Waiting for Review
• Under Review
• Done

Types

We have different kinds of issues:

• Documentation: For any issue that is not code related.
• Bug: Reporting a bug.
• Urgent: For unexpected problems that need to be fixed as soon as possible.
• Enhancement: For newly proposed features that are not required by the description.
• Refine: For issues related to refining already working code for better code quality.
• Abandoned: We shall no longer be working on this issue.

Keep in mind that just being close to the deadline does not make an issue "Urgent". The issue has to be unexpected (might be a bug or a requirement done wrong), close to the deadline, and has significant impact on the project

Labels

We have different kinds of labels for each issue:

• half-way checkpoint: For user stories that we have to present at half-way checkpoint (part 3)
• help needed: When you took too much time on an issue and you are not coming up with a solution, you can post an issue with this tag (an with description as detailed as possible) to ask for help.
• Risk Level: Low/Medium/High: Used for risk analysis. The more risk the feature has (i.e. if this feature breaks, many others will), the higher the risk level.
• Size: 1/3/5/8: Size of user story, which estimates the time needed to finish the story by assigning story points. Each point estimates 2 hours of work.

Milestones

We currently have 3 milestones for documentation and 4 milestones for app implementation:

• For documentation:
  • Project Part 2: Preparation
  • Project Part 3: Half-way Checkpoint
  • Project Part 4: Final Checkpoint
• For app implementation:
  • User Story: Ingredient Storage
  • User Story: Recipes
  • User Story: Meal Plan
  • User Story: Shopping List