-
Notifications
You must be signed in to change notification settings - Fork 0
Development Guidelines
This page contains a set of guidelines and conventions for the entire development process. There may be additional points along the way.
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.
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.
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:
- 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)
- Avoid the use of deprecated features.
- Avoid lines longer than 80 characters.
Some of these conventions are taken from those introduced in CMPUT 301 document: Code Conventions (Schoepp).pdf
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.
Currently, we have 5 kinds of status. The name of each is self-explanatory:
- Todo
- In progress
- Waiting for Review
- Under Review
- Done
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
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.
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