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:

• Sprint meetings.
• 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.
• Avoid the use of deprecated features.

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

Conventions

We are required to follow some coding conventions