Team XENA SOEN 390: Simple Camera App

This application includes integration of three features:

1. Filters
2. Voice Activation
3. Geotagging
4. QR Scanner*

***We implemented an extra bonus feature: QR Scanner.

Our Team Meeting Minutes can be obtained here.

Team Policies

The following policies will indicate the minimum requirements and expectations that are to be followed for project management and planning purposes. If these are not met, they will either be edited by team leader: @milaroisin or indicated as lacking wherever appropriate.

Pull Requests

Every pull request must have the following:

• Reference the task (if a separate issue has been made) or user story being addressed
• Minimum of 2 reviewers and 2 approvals for the pull request to be merged
• Minimum of 2 comments in code and 1 overall comment (whether it is for an approval or request for changes, unless previous comments have accounted for approval/changes reasons) per reviewer. Comments such as this looks good, runs fine, good job, etc. will be indicated as insufficient. Also, vague reviews (use of words like appears, seems, looks like, etc.) need to be avoided as they essentially imply uncertainty. This strict minimum can be softened for pull requests that involve fixing a bug, code refactoring, very small commits, or merging already pull requested code from develop into master.
• Label the pull request with the feature being implemented and the sprint in question. If the pull request is for an environment fix or something else in particular, it will be labelled as such Reviewers assigned to pull requests need to address them (comment, approve, etc.) within one day of the pull requests' creation.

Making Issues for Tasks of a User Story

For sprints 4 to 6 (releases 2 and 3), separate issues will be made for each task of a feature-based user story issue (thusly excludes stories addressing documentation, design or testing concerns). These task issues need to have the following:

Reference the user story

• Assignee (maximum 1 person for traceability). Otherwise, do not break apart the story issue into separate task issues
• Risk assessment (high, medium or low)
• Priority assignment
• Number of story points
• Applicable labels, namely task and the feature type (or simply add the label environment, documentation, etc. if the task can be categorized as such)
• Add it to the "To do" in "Projects" and indicate the "Sprint" Commits
• Each and every single commit needs to consist of the following:

Always reference the task (if a separate issue has been made) or user story being addressed (this is of the utmost importance) Indicated the purpose of the commit. Specifically, indicate the 'why' of what was done. Was it an addition? Was it a fix of something already present? Explain the commit based on these kinds of questions.