cAR SPMP

Version 1.0

Table of Content

• 1 Overview
  • 1.1 Project Summary
    • 1.1.1 Purpose, Scope, and Objectives
    • 1.1.2 Assumptions and Constraints
    • 1.1.3 Project Deliverables
  • 1.2 Evolution of the SPMP
• 2 References
• 3 Definitions
• 4 Project Organization
  • 4.1 External Interfaces
  • 4.2 Roles and Responsibilities
• 5 Managerial Process Plans
  • 5.1 Project Start-up Plan
    • 5.1.1 Estimation Plan
    • 5.1.2 Staffing Plan
    • 5.1.3 Resource Acquisition Plan
    • 5.1.4 Project Staff rtaining Plan
  • 5.2 Work Plan
    • 5.2.1 Work Activities
    • 5.2.2 Resource Allocation
  • 5.3 Control Plan
    • 5.3.1 Requirements Control Plan
    • 5.3.2 Schedule Control Plan
    • 5.3.3 Reporting Plan
    • 5.3.4 Metrics Collection Plan
  • 5.4 Risk Management Plan
  • 5.5 Project Closeout Plan
• 6 Technical Process Plans
  • 6.1 Methods, Tools, and Techniques
  • 6.2 Infrastructure Plan
• 7 Supporting Process Plans
  • 7.1 Configuration Management Plan
  • 7.2 Verification and Validation Plan
  • 7.3 Documentation Plan
  • 7.4 Reviews and Audits Plan
  • 7.5 Problem Resolution Plan
  • 7.6 Process Improvement Plan
• 9 Plan Annexes

1 Overview

1.1 Project Summary

1.1.1 Purpose, Scope, and Objectives

The purpose of this project is to create a mobile application to help project a car in the environment they are in using Augmented Reality. The user could use it to walk around the virtual car to see it upclose inside and out with detail that would otherwise not be possible in photos. This would also let them see if the car could fit in their garage. This product would allow users to hear the engine noise, view a description and rating of the car, and visit Autotrader to view listings of the car if the user would like to purchase the car. The user can also record a video in the application, which they can save and share to others in social media. Finally, they can write suggestions regarding improvements for the application.

1.1.2 Assumptions and Constraints

Assumptions:

• It is assumed that the user will have a phone compatible with the required toolkits, such as ARKit or ARCore.
• The list of mobile devices that are compatible with the toolkits are listed in the requirements document.
• It is also assumed that the user has enough space on their devices to download the app and additional space if they wish to save the recorded video.
• The user must be able to navigate through the app and interact with the features.
• It is also assumed that the user will be connected to the internet for viewing the autotrader website with the cars listed on it.

• A few constraints for the schedule are that group members have different times of availability and therefore are not able to make it to meetings regarding important decisions for the project.
• There is no project budget, therefore the team cannot use resources that require payments. Therefore effective but free tools/resources must be looked for and used.
• Software that will be reused needs to be open source or tutorial code, therefore finding good and free reusable software that will need to be tested rigorously may prove difficult to find.

1.1.3 Project Deliverables

The following deliverables will be submitted as files. The requirements, software project management plan, analysis, and design are part of the documentation and will be linked to the website provided as HTML files. cAR will be an app on newer Android and Apple smartphones. If the client does not own an appropriate device to install the app themself, they will be provided a demonstration of the app from the phone of a project team member.

1.2 Evolution of the SPMP

As this SPMP is put into action, there will be unscheduled modifications to the plan as issues arise and are resolved. After the initial version of the SPMP is completed, suggested revisions will be submitted to the Documentation Manager for approval and the document will only be updated once approval is granted. All changes to the SPMP must be finalized by the project due date, August 5, 2021.

2 References

• cAR Software Requirements
  • Report number: version 1.0
  • Publication Date: May 28th, 2021
  • Authors: Lovette Oyewole, Zhenyang Ding, Kanav Kaura, Muhammed Mirza, Jordan Den Hoed, Berk Yilmaz
• IEEE Standard for Software Project Management Plans
  • Report number: 1058-1998
  • Publication Date: December 22nd, 1998
  • Authors: Software Project Management Plans Working Group of the Software Engineering Standards Committee of the Computer Society of the IEEE
  • Publishing Organization: Institute of Electrical and Electronics Engineers, Inc.
• CP317 Spring 2021 Course Website
  • Publication Date: May 10th, 2021
  • Author: David Brown
  • Publishing Organization: Wilfrid Laurier University, Department of Physics and Computer Science.
• https://www.merriam-webster.com/
  • Publication Date: 2021
  • Publishing Organization: Merriam-Webster
• https://www.alphr.com/google-docs-to-html/
  • Publication Date: March 12th, 2019
  • Author: Robert Hayes
  • Publishing Organization: alphr

3 Definitions

Definitions adapted from Merriam-Webster definitions

Backend: The part of the software that is not visible or accessible to the user

Frontend: The part of the software that is visible to the user e.g. the Graphical User Interface (GUI)

Software Quality Assurance (SQA): The quality assurance process that requires a section of a document or code to be approved by a peer before being completed.

User Interface (UI): Software that allows the user to interact with the operating system of a machine or system

Graphical User Interface (GUI): A system of interactive visual components for computer software.

Rapid Prototyping: A visual expression of what the frontend will look like. Result is a nonfunctional GUI.

Software Development Kit (SDK): A package containing a number of software development tools that can be installed. They aid in application development by providing a compiler, debugger, and a software framework.

Database: A usually large collection of data organized especially for rapid search and retrieval (as by a computer)

Show Stopper: A glaring bug in the software that affects the overall integrity of the product.

Product Sectors: A project sector refers to the subsection of the product’s software, such as the backend, and frontend that make up the entire product.

4 Project Organization

4.1 External Interfaces

The client for this project is the professor for CP317 (Spring 2021), David Brown. The team’s communication person, Zhenyang Ding, is responsible for all reporting to the client, via email. Bi-weekly meetings with the client, via Zoom video call, are also necessary for further clarification. At least one member of the team is expected to join this meeting and take notes for other members to read.

4.2 Roles and Responsibilities

Role explanations:

• Logo Design: Creates and modifies designs for the cAR logo until one can be agreed upon.
• Contact Person: Responsible for communicating with the client and delivering findings.
• Discord Admin: Sets and tracks attendance of group meetings, reminds all members of important decisions.
• Website Management: Converts written documentation to HTML and adds it to the documentation website shared with the client. Also manages and updates this website as the documentation changes.
• SQA Maintenance: Ensures that all code and documentation receives SQA and maintains a document keeping track of SQA comments.
• Time Log Maintenance: Ensures that all members enter time spent on the project for the week every Friday at noon. Calculates total time each member spent on the project at the end of the development.
• Documentation Management: Writes, assigns sections, and updates past documentation. Informs group if changes are made.
• Documentation: Writes the analysis documentation and is eligible for performing SQA on it for sections that they did not write.
• Documentation Maintenance: Periodically checks past documentation and updates it if necessary.
• Programming Management: Codes, assigns work for frontend and backend, and acts as liaison between programming and documentation.
• Frontend: Works on programming the interface that a user directly interacts with. Works with backend programmers to ensure all code works together.
• App Design: Responsible for designing and coding the application aesthetics. Is part of frontend development.
• UI: Responsible for coding the user interface. It is a part of frontend and app design.
• Prototype Maintenance: Responsible for rapid prototyping and updating the GUI as the project progresses.
• Backend: Works on programming and adding utility for the frontend as well as everything on the server and database side. Works with frontend programmers to ensure all code works together.
• 3D Modelling: Manipulate 3D models that will be used for the AR projection to ensure it aligns with the actual dimensions and features of the car as well as projecting onto a flat surface correctly. Also collects feedback on accuracy and representation of each AR car. Part of the backend.

Individual responsibilities:

• Attend group wide meetings if possible
• Attend small meetings organized by the section manager
• Inform and keep the group Trello boards up to date, in terms of moving the cards in the appropriate place.
• Ask for an SQA, and make sure to apply or deny those suggested changes.
• Log their hours on a weekly basis, Friday at noon.

Requirements Documentation

SPMP

Analysis

Design

Future Roles

Regular meetings will be held on Discord to ensure synergy among all levels of production. Additionally, the requirements and SPMP documents will be used by the team members as references.

5 Managerial Process Plans

5.1 Project Start-Up Plan

5.1.1 Estimation Plan

Deadlines are created based on the schedule provided by the client. Resource requirements and tools are influenced by the features the application will have. For example, using Flutter SDK in order to have both iOS and Android versions of the app. Re-estimation of the schedule is contingent on the possibility of tasks completion and will be approved by the entire team. Changing resources or deadlines would be discussed as a group and done as necessary. The appropriate updates on documentations would also be done by maintenance throughout phases of the project. Changes to project costs due to storage of the car models on the cloud will be considered as a group. For example, if the amount of writes or reads exceeds the free plan, changing the plan would be required to keep the application functional at all times. If there are conflicts, a poll will be held.

5.1.2 Staffing Plan

Each team (Documentation, Frontend, App Design, Backend, and Code Integration) will start off with 4 spots for members to join/sign up for, however spots may be added or removed depending on the complexity of the job performed by that team. Every member of the group must have basic programming knowledge. All members should be able to solve minor problems on their own but be able to clearly consult with the rest of the group on bigger issues. More specifically, during the project's implementation phase, the implementation team will require members that have experience in coding and understand basic data structures. They will need to know how to code in Flutter and communicate effectively with the rest of the team. They will also need to know about databases, Swift, Java, and working with ARCore and ARKit APIs. Throughout the project the documentation team requires its members to be capable of collecting information from other teams and document it (or update the document). Additionally, they should be willing to read through approximately 20 page documents to follow the rules and criteria for documenting the project. Individuals should pick which parts of the project they would like to work on based on their strengths.

5.1.3 Resource Acquisition Plan

The acquisition of resources is the responsibility of the individual team members. This includes a computer that is connected to the internet, which is used to develop the application as well as communication with other members. Smartphones are also needed, including an iPhone and Android phone to test the cAR application and can also be used for communication. All members must have their own computer to work on and those responsible for testing require a smartphone. These are the only resources that are needed for the development of cAR in all stages.

5.1.4 Project Staff Training Plan

Training will be given to members that are part of the implementation team which will consist of learning how to use Flutter, basic links will be provided to review data structures (more for the backend members). There are approximately 12 members of the implementation team, however that may change in the future if a member leaves or joins a team. The links for courses and free tools are provided, the members must learn flutter during the week of May 30th 2021 and preferably before June 7th 2021. If any questions arise, the members can reach out to each other and/or the manager for the implementation team and then a meeting (or more) will be arranged. Another method of training for all members is to refer to lecture notes, videos, and attend office hours held by David Brown. All members were given training on how to use Trello and be able to communicate with the group effectively and log their hours. However, managers were also trained to host meetings for their team.

5.2 Work Plan

5.2.1 Work Activities

The group must complete work activities in order to meet milestones and deadlines. Past and current activities are listed in detail, while planned activities are outlined and will be elaborated upon in the future. The overall activities required to complete this project are listed below:

1. Coming up with ideas for project
   1. Sign up on Discord and MLS
   2. Join GitHub repository
2. Documentation phases (Requirements, SPMP, Analysis, Design)
   1. All members responsible for writing join Google Drive folder and locate document
   2. Fill in the relevant sections
   1. Group members attend meeting to assign subsections
   2. All subsections are volunteered for or forcefully assigned
   3. Get sections reviewed
      1. When finished, author requests SQA
      2. If nobody volunteers for SQA for many hours, it is forcefully assigned.
   4. Convert written documentation into website format
      1. Ensure documentation follows writing standards
      2. Convert the document into HTML with an HTML converter tool
      3. Clean up the new HTML document and fix conversion errors
   5. Add the HTML documentation as a link on the documentation website sent to the client
3. Software Project Management Plan
   1. Same steps as 2
4. Members split into different categories of roles - Documentation, frontend, and backend
   1. Miscellaneous roles may require only 1 person, such as management positions and prototype maintenance
5. [Future] At least one member must learn the basics of Flutter by June 6-7.
6. [Future] Analysis documentation
   1. Same steps as 2, except instead of all members, only those in the documentation category are involved in writing
   1. Still requires collaboration with other categories
7. [Future] Pick languages to be used for backend
8. [Future] Design documentation
   1. Same steps as 6
9. [Future] Implementation
   1. Development of database
   1. SQA
   2. Coding
   1. SQA
10. [Future] Deliver product to client

5.2.2 Resource Allocation

Common resources:

• Almost all resources will require members to have an internet connection but it is not provided.
• All teams/members of the group will have access to Google Drive, Discord, Trello, GitHub, and Laurier emails.
• Discord is the main communication method.
• Trello is used to organize the list of things that need to be completed, are in the process, and/or are completed.
• Google Drive is used to write/prepare all the documents that are vital for the project.
• GitHub is used for programmers to work on and share code easily.
• If members require assistance or clarification, meetings can be arranged by the managers to get everyone in the group together and go over the issues/concepts
• General team meetings will be held at least once a week, with more frequent meetings nearing deadlines.

Resources allocated to Documentation:

• This includes the resources allocated to the SPMP document.
• The documentation team will mainly use Google Docs and Google Sheets in Google Drive but other applications provided may also be used.
• The documentation team consists of about 6 members but more members from outside the team can help and contribute.
• Each member working on documentation must be able to track information and verify that the written information is accurate to information in other locations so that there are no conflicts.
• The team must also be able to construct a document with proper punctuation and grammar as well as proper documentation according to the IEEE standards outlined in IEEE documents and lecture notes.
  • Both sources are provided to the documentation team.
• Another resource that is available to the team is GoogleDocs2Html, which is a tool used to convert the documentation into html .This requires no training, individuals only need to follow the tutorial provided in the README file. Website management edits the resulting file and updates the website accordingly. This task requires basic knowledge of HTML.

Resources allocated to Implementation:

• Prior to the implementation phase, members of the implementation team are provided with links to courses, free videos, and articles on learning Flutter and Dart for frontend programming.
• Programmers will also be provided with links to notes and videos regarding data structures as a review of what they should already know for the backend programming.
• More detail as the project progresses.
• Each member of the team must know the basics of data structures, and should be able to understand any further needed data structures never studied before.

5.3 Control Plan

5.3.1 Requirements Control Plan

Any significant changes that affect the product requirements have to be approved by at least one member of the group. Each time changes are made, the html file should be updated by website management, Lovette Oyewole. Additionally, through Github, version control is ensured. If the changes affect the project schedule, the team should be notified on Discord.

5.3.2 Schedule Control Plan

The schedule for each team (documentation, frontend/UI, backend, and integration teams) will be managed by the team’s respective manager, which group members were given a chance to sign up for previously. The manager of each team will then create a schedule to determine which tasks have to be completed and deadlines for them. The manager will then communicate with the rest of the team members to assign tasks to each member of the team. Using TimeCamp, which is embedded into Trello, team members will track how much time they spend on each task and will be reviewed by the manager at the end of each week. Each team member is responsible for reporting accurate updates of their task status to the team manager at each team meeting. If the team begins to run behind schedule, the manager will collaborate with the rest of the team to brainstorm a solution to create a more reasonable schedule and ensure the schedule is followed in a timely manner.

5.3.3 Reporting Plan

Teams are split into groups which are based on the roles outlined in section 4.3. Each group has a manager that group members will report to. Managers of the group will meet with other managers to give updates of group progress and discuss any changes, if necessary. Meetings for groups are planned according to when members are available. Availability times for each member are written on a timesheet. Group meetings are done regularly using Discord and Zoom and occur weekly, with extra meetings occurring as deadlines approach. Applications including Trello and GitHub are used to track progress and display who authors are.

5.3.4 Metrics Collection Plan

Metrics for the deliverables, listed in clause 1.1.3, shall be received from the client. Metrics are also provided through SQA and versioning. At the end of the semester, each individual is rewarded a project mark that is determined by the level of their contribution. Some of the following are deciding factors:

• Ability to follow through on one’s word
• Team member ratings
• Team member participation records

5.4 Risk Management Plan

The product should go through wide-ranging testing to prevent user information being exploited. Members from the design team should focus on making sure all aspects of the application are user friendly and easy to use as the user could be inexperienced using a mobile application. All code should be tested by multiple members including the design workflow to gain different perspectives to ensure correctness and prevent potential bugs. Using AR development kits, the application can increase in storage size easily. The application should not take up too much storage space on a mobile device and should be equivalent to other AR related apps. The application should handle the influx of users and their data. Servers must be large enough to have users logged in and using the application concurrently and have protections in place to prevent denial-of-service attacks (DDOS) and Structured Query Language (SQL) injection. Databases must have enough space to store user information, and be encrypted using modern security protocols in order to protect user data, specifically passwords. The database design will be protected from leaks and breaches by staff training, frequent auditing and maintenance

5.5 Project Closeout Plan

Project cAR will end on August 5th 2021. At the end, the group will collectively:

• Provide soft copies of all documentation/documents to the client.
• Archive project materials which include documents, source code, SPMP, requirements documentation, and reference materials.
• Members will join a postmortem meeting in which they will observe the project from the initial phase to the end result and debrief where the project succeeded and what needs to be further improved.
• The group will also provide a final report which includes information such as the lessons learned and the analysis of project objectives archived. This will be provided to the client at the end.

6 Technical Process Plans

6.1 Methods, Tools, and Techniques

For documentation, Google Docs will be used as a shared document for the Documentation team to collaborate and then the completed document will be converted into an HTML file to be read online.

Discord and Zoom will be used for communication among project members.

The code for the cAR application will be written using Dart (for Flutter 2.2), Java, and Swift. Xcode 12.5 will be used to develop and test the iOS-sided applications, while Android Studio 4.2 will be used to develop and test the Android-sided applications. MySQL Free will be used to manage the application-local database for individual car listings, along with their 3D models. Google Firebase will provide user authentication and user data security.

The phones used to test the cAR app will be Apple iOS (11.0 or later) and Android OS (7.0 Nougat or later). Use of the app will require a Wi-Fi connection established via the WLAN protocol.

6.2 Infrastructure Plan

Members working on the cAR project have access to their own workstations which either use MacOS or Windows 10 for development. The team uses Google Drive to store and share documents as well as spreadsheets to keep track of progress. Trello is also used to help organize the team, allowing members to assign tasks which are not yet completed. Other people on the team will see who is working on a given task and will also notice what kind of progress has been made. Members will communicate with each other using Discord along with Zoom for virtual meetings. The user interfaces will be created using Adobe Xd which will be exported to Flutter using the Xd to Flutter plugin where the team will provide functionality to the user interfaces. Everyone on the team will use GitHub to store the project with version control. Members will use a mobile device running either Android or iOS to test the application.

7 Supporting Process Plans

7.1 Configuration Management Plan

By using an organization service called Trello, different teams will have different boards in order to help organize what is done, what is being worked on, and what is to be changed. Each team will have their own sections to be used for their tasks and deadlines. After finishing a build, it will be tested and if there needs to be any changes, it will be indicated on the Trello board. As the teams work to fix those errors and add new features, once finalized, they will be released to update the current build of the project and a number system will be put in place in order to keep track of our current and past version builds. The front-end team will be in charge of the way the app looks and it's user-experience design, whereas the back-end team will be focused on making sure the technical aspect (AR functionally, car models, and cloud storage) of the project is functioning. Once both teams agree that their sides are stable, they must work together in order to create an entirely functional app that will be tested. Functions that are not behaving correctly will be noted as well as any bugs, glitches, and overall ease of life changes. Major changes and features will be discussed with everyone and a vote will decide what will be added into the next update. Both teams will work on their respective sides and repeat the process until we end up with a product/build that everyone is satisfied with.

7.2 Verification and Validation Plan

Documents Verification Protocol

External tools: Trello

While creating the supporting documents, individual contributors follow a software quality assurance (SQA) protocol, as described in section 9.

Software Development Validation Protocol

External tools: Git, GitHub, Trello time tracker

The product shall be built using a testing driven development through its development cycle.

Once the software design of the individual sections of the entire product has been agreed upon, each UML class will be assigned a Trello card. The Trello card shall specify a list of test inputs for testing the functions and shall list a corresponding list of valid outputs per test case.

Members of the individual development team will then acquire a set amount of cards and complete the task of building the specified classes and their corresponding functions.

Once each class and its functions are built, the individual developer shall perform a unit test of the individual functions and shall provide a screenshot of the unit test’s input and corresponding valid outputs. This screen shot shall then be added to Trello card, it shall then be labelled as “NEEDS REVIEW” and then a pull request to the Git repository shall be sent.

Two individuals of the development team, other than the authors of the class, must then perform a code review and verify the authenticity of the inputs and corresponding outputs in the given screenshot. Once the code review comments have been addressed, the manager of the development team can then approve the pull request.

Throughout this process, a timestamp shall be created in the Trello card, for when the code review process started and when the pull request was accepted.

This process establishes a record of the product’s verification.

7.3 Documentation Plan

Non-Deliverable Documents:

• Software Requirements Document, IEEE Requirements Template,Std 830-1998
• Software Design Document, IEEE Design Document Template, Std 1016
• Software Verification Document.
• Meetings Attendance
• Individual Contributions and time tracking list

Deliverable Documents

• Source Code
• User Guide/Document

7.4 Reviews and Audits Plan

Both the documentation and code created during the cAR app project are reviewed and audited via the SQA process. When a section of a document or code is considered “complete” by the team member who wrote it, it is flagged for SQA. A different team member then reviews the section and determines if there are any flaws, inconsistencies, or something missing from it. Their suggestions are then written in a separate document and the original author can make changes to their work as needed. Every section of code and documentation must undergo the SQA process before it is complete.

7.5 Problem Resolution Plan

Show Stoppers

If a glaring software bug is found in a specific sector of the product that affects the overall integrity of the product, an immediate message shall be sent in the specific development discord channels of the corresponding software sector, with the @everyone tag. If the bug in question involves the other sectors of the product, or a possible fix shall affect the other sectors of the product, then the “@everyone” message shall also be sent to the discord channels of said product sector.

An immediate meeting must then be scheduled with all the developers of the product sectors involved.

In such a meeting, a consensus will be reached upon consultation with the developer(s) who were involved in the development of the failed software element. They will identify the next steps needed to resolve the issue, and will put forth any requests for additional resources in the meeting. When a solution has been agreed upon, a Trello card will be created for the bug and shall be labeled as “URGENT SHOW STOPPER”.

When a show stopper bug is discovered and assigned to a set of developers, all work on other features assigned to said developers will cease immediately, until a fix for the Show Stopper bug has been approved for a pull request, by the manager of all the teams that are affected by the bug.

Ordinary Bugs

In the event of an ordinary bug, with side effects contained to a single product sector, a Trello card shall be created immediately in the board for the corresponding product sector.

The card shall describe the bug and be assigned to a member of the development team, at the discretion of the team's manager.

In addition, the individual developer identifying the bug will then contact the original author of the product sector using the group Discord communication channel. In case the original author is unable to resolve the issue, the manager will be involved in identifying any additional resources required to resolve the bug.

7.6 Process Improvement Plan

Task assignment, especially for documentation, has met with some organizational issues resulting in work being completed too close to the deadline. There has been difficulty with assigning tasks too late, members missing information, and a lack of organization around scheduling group meetings. The documentation manager will be responsible for creating a Google Doc with a brief explanation of the process to complete the current documentation. This Google Doc will include links to relevant notes, signup locations for sections and SQA, a place to input when members have time for a meeting, and explanations of miscellaneous processes such as tracking time and how to perform SQA. The documentation manager will then directly send this document to everyone in the documentation category and set a deadline for a response at most 1 day after sending. The documentation manager will then schedule a meeting around the availability of members and send the time directly to the members. During the meeting, the documentation manager must go through the documentation and formally assign at least one member each for writing and SQA for every section. The team members will give an approximate time for when they will finish their work before the documentation manager assigns a milestone date for the entire group. Sections with no assigned volunteers will be assigned as per the level of expertise and total participation of the group members. The documentation manager will record these tasks and deadlines and check in with team members accordingly, while coordinating with programming categories through the programming manager.

9 Plan Annexes

The process of SQA for this project is as follows:

1. Author completes work and is confident it is ready to be revised. The respective card for the task, on Trello, is moved to the “SQA Needed” list.
2. Author attaches a blue label to the respective card on Trello.
   1. When applicable, the author also highlights the section title on the document red.
3. Individual(s) assigned to SQA the task adds comments to the SQA file and changes the status field to yellow. A yellow label is added to the card.
1. When applicable, the section title is updated to yellow.
4. SQA person(s) notifies the author.
5. Author reviews suggested changes and chooses to accept/reject.
6. The SQA file is updated to catalog actions that took place regarding the decision.
1. If changes are accepted, the status field is changed to green and the author includes comments, if needed.
2. If changes are rejected, the status field is changed to red and the author includes justification as comments.
3. When applicable, the section title is updated to green.
7. The author updates the card, by attaching a green label.
8. Once a card has a green label, it should be moved to the “Done” list.

Authors

Kanav, Muhammed, Zhenyang, Jordan, Lovette, Abhirup, Hilal, Joanne, Matthew, Sameer