edited readme for grammar

README.md

@@ -1,20 +1,8 @@
 # Project Repository
 
 ### Project Description
-This web app is for music fans to rank and discuss music.
-
 - Product Vision Statement: Our app is a music ranking app that allows users to view songs and leave rating and comments about their thoughts. Users are allowed to create accounts and choose to log in and log out. They can also search for individual songs that they want to rate as well as look at the current reviews for that song. Users can also comment under these posts or create a post of their own. Our app also allows for people to view other profiles to see what other posts and comments other users have left. The goal of our product is to create a community of users where they can actively share their thoughts on songs as well as see and communicate with other peoples views. This allows users to not only learn more about songs they might not have heard yet but also receive opinions from other users that may align or clash with their own thoughts.
 
-    Users can:
-    * login/logout
-    * search for individual songs
-    * rate individual songs
-    * post written reviews
-    * post comments on written reviews
-    * see other users' profiles
-
-
-
 ### Team Members
  - [Athena Leong](https://github.com/aleong2002)
  - [Jaylyn Bido](https://github.com/jaylynb26)
@@ -31,6 +19,4 @@ See [CONTRIBUTING.md](./CONTRIBUTING.md) for information on project contribution
 *to be updated at a later stage*
 
 ### Additional Links
-*links to any additional Markdown documents or web pages that may be relevant to the project*
-
 - [SpotifyAPI](https://developer.spotify.com/documentation/web-api)

instructions-0d-sprint-planning.md

@@ -4,73 +4,31 @@ Scrum follows a specific process by which teams plan the work that will be done
 
 ## Creating the Sprint Backlog
 
-<<<<<<< HEAD
-Each team will hold a [Sprint Planning session](https://knowledge.kitchen/Scrum_development_framework#Sprint_planning) to decide which User Stories from the Product Backlog to include in the Sprint Backlog for the upcoming sprint. The team must follow the established procedure for holding sprint planning sessions.
-
-View a [video overview of creating the Sprint Backlog in GitHub](https://youtu.be/-MBEnpAgmug).
-=======
 Each team will hold a [Sprint Planning session](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/scrum/#71) to decide which User Stories from the Product Backlog to include in the Sprint Backlog for the upcoming sprint. The team must follow the established procedure for holding sprint planning sessions.
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30
 
 ### Elaborating the User Stories
 
 Each User Story added to the Sprint Backlog must...
 
-<<<<<<< HEAD
-- include [Acceptance Criteria](https://knowledge.kitchen/Scrum_development_framework#Acceptance_Criteria) included in it [as a checklist](GitHub_for_team_collaboration#Creating_a_new_issue)
-- be assigned the `Sprint N` Milestone, where N is the number of the current sprint, in GitHub's Issue tracker
-- include an [Estimation of effort](https://knowledge.kitchen/Scrum_development_framework#Estimation_of_work), which teams calculate following the Planning Poker effort estimation processes
-
-User Stories in the Sprint Backlog must also follow the basic requirements for User Stories
-=======
 - follow the basic requirements for User Stories
 - be assigned the `Sprint N` Milestone, where `N` is the number of the current sprint, in GitHub's Issue tracker
 
 User stories may optionally also...
 
 - include [Acceptance Criteria](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/scrum/#61) included in it [as a checklist](GitHub_for_team_collaboration#Creating_a_new_issue)
 - include an Estimation of Effort, which teams calculate following the Planning Poker effort estimation processes
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30
 
 ### Breaking User Stories into Tasks
 
 Once the team has selected User Stories to include in the Sprint Backlog, the team must then create the individual Tasks and Spikes that are necessary to implement each the User Story.
 
-<<<<<<< HEAD
-Tasks are the smallest unit of work, and should typically be doable by one person in one day. In a class setting, we will define Tasks as completable by one person between one Standup meeting and the next Standup meeting.
-
-Tasks are those things that must be done to complete the implementation of the User Story
-
-- these include tasks for each of the things that are necessary according to your team's definition of done
-=======
 A Task is the smallest unit of work. Together, the Tasks related to a single User Story are those things that must be done to complete the implementation of that User Story.
 
 Tasks should typically be doable by, at most, one person in one day. But in a class setting, we will define Tasks as completable by at most one person between one Standup meeting and the next.
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30
 
 Each task must...
 
 - be made its own Issue in GitHub's Issue tracker
-<<<<<<< HEAD
-- be assigned the 'Sprint N' milestone, where N is the number of the current sprint.
-- be labeled with the 'task' label to differentiate it within GitHub's Issue tracker from 'user story' Issues
-- include in its initial description the Issue number of the User Story from which it was derived
-- include the number sign, e.g. "This task is part of User Story #4"
-
-View a [video overview of creating the Sprint Backlog in GitHub](https://youtu.be/-MBEnpAgmug), which includes how to break up User Stories into Tasks.
-
-### Spiking the backlog
-
-This initial product backlog must include 'spikes' for investigating which technologies to use for the project as well as setting up each team member's local development environment.
-
-- These spikes are highest priority and must be completed as soon as possible during the Sprint - Spikes must be given the 'spike' label and the 'Sprint N' milestone, where N is the number of the current sprint, in GitHub's issue tracker
-
-### Planning poker cards
-
-Each team must agree on a way of estimating work. This can be any of the [work estimation methods](https://knowledge.kitchen/Scrum_development_framework#Estimation_of_work) that we have discussed.
-
-If a team chooses to go with the [Planning Poker](https://knowledge.kitchen/Scrum_development_framework#Estimation_of_work) estimation method, the team must agree upon a deck of cards that they like and will use for work estimation
-=======
 - be assigned the '`Sprint N`' milestone, where `N` is the number of the current sprint.
 - be labeled with the '`task`' label to differentiate it within GitHub's Issue tracker from '`user story`' Issues
 - include in its initial description the Issue number of the User Story from which it was derived, e.g. `Related to user story #22`
@@ -88,7 +46,6 @@ Spikes must be given the '`spike`' label and the '`Sprint N`' milestone, where `
 Each team must agree on a way of estimating work. This can be any of the work estimation methods that we have discussed.
 
 If a team chooses to go with the Planning Poker estimation method, the team must agree upon a deck of cards that they like and will use for work estimation
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30
 
 - it's ok to design your own cards if you have visually or conceptually creative team members
 - it is not ok to use Planning Poker software in place of physical cards - doing so goes against the raison d'être of Scrum
@@ -97,24 +54,9 @@ If a team chooses to go with the Planning Poker estimation method, the team must
 
 ### Setting up the task board
 
-<<<<<<< HEAD
-Each team will maintain a shared Task Board for each Sprint [using
-GitHub's Project Board functionality in the recommended
-fashion](https://knowledge.kitchen/GitHub_for_team_collaboration#Project_boards). These
-boards are available under the 'Projects' tab in GitHub - you will
-have to set up the Sprint task board in recommended fashion.
-
-- Add all User Stories to be addressed during the Sprint into the
-  "Sprint Backlog (User Stories)" column - Add all Tasks for each User
-  Story into the "To Do (Tasks)" column
-
-Once you start working on tasks, you will move them to the other columns
-depending on their current status.
-=======
 Each team will maintain a shared Task Board for each Sprint [using GitHub's Project Board functionality in the recommended fashion](https://knowledge.kitchen/content/courses/agile-development-and-devops/scrum/github-project-management). These boards are available under the '`Projects`' tab in GitHub - you will have to set up the Sprint task board in recommended fashion.
 
 - Add all User Stories to be addressed during the Sprint into a "`Sprint N - Backlog`" table view.
 - Add all Tasks and Spikes for each User Story into the "`To Do`" column of a `Sprint N - Task Board` board view.
 
 Once you start working on tasks, you will move them to the other columns depending on their current status.
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30

instructions-1-front-end.md

@@ -1,10 +1,6 @@
 # Front-End Development
 
-<<<<<<< HEAD
-Each team must have completed and [demo'd](https://knowledge.kitchen/Scrum_development_framework#Demo_for_Stakeholders) the working front-end of their group project by the end of the corresponding Sprint.
-=======
 Each team must have completed and [demo'd](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/scrum/#91) the working front-end of their group project by the end of the corresponding Sprint.
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30
 
 ## Technical requirements
 
@@ -15,29 +11,6 @@ The following requirements outline what must be, must not be, and may be done du
 - All front-end code must be generated using React.js.
 - All component definitions must be written as **functions**, not as classes.
 - All component content must be written using **JSX**, not only plain Javascript.
-<<<<<<< HEAD
-- All styles must be custom-coded in external CSS files - one for each component.
-- Basic layout of each screen must be accomplished using the CSS flexbox system.
-- Front-end screens must be custom-designed to look clean, contemporary, and sharp, not like a wireframe.
-- Any data that will ultimately come from a back-end server or API in the completed application must be mocked for now using the mock-API tool, [mockaroo](https://mockaroo.com/mock_apis), or another similar tool if Mockaroo is not sufficient for a justifiable reason.
-- Any user-generated images that will be displayed by your app must be temporarily mocked with a random image API service, such as [Picsum](https://picsum.photos/).
-- Front-ends must include all screens in the completed application and should closely match the clickable prototypes created previously, unless the team believes an alternate user experience is beneficial.
-- Ay mismatch between the clickable prototypes and the front-end app code delivered must be explained during the stakeholder demo.
-- If your app will eventually have user registration and login functionality, all front-end screens to support this must be created, although they should be non-functional for now.
-- Instructions on how to set up and run the project must be included in the README.md file in version control. It must be possible for anybody to follow the instructions on the README.md to build and run the entire project on their local machines.
-
-### Must nots...
-
-- State managers, such as [Redux](https://react-redux.js.org/) or [Mobx](https://mobx.js.org/README.html#introduction) must not be used.
-- Account registration or log in functionality must not be included - that can be added later during back-end development. But do include the non-functional screens for these.
-- Any data that will be coming from a server or API must not be hard-coded within your front-end code... mock the API for now and fetch the data from the server within the front-end code.
-- Any user-generated images must not be hard-coded in the front-end code, but must be mocked with a random image service for now.
-
-### May...
-
-- You may use front-end design frameworks, such as [Bootstrap for React](https://react-bootstrap.github.io/) or [Material UI](https://material-ui.com/).
-- You may use a 3rd-party module, such as [react-burger-menu](https://github.com/negomi/react-burger-menu) for a hamburger menu or other [primary navigation](https://knowledge.kitchen/Navigation_components#Global_Navigation).
-=======
 - Front-end screens must be custom-designed to look clean, contemporary, and sharp, not like a wireframe.
 - Any user-generated images that will be displayed by your app must be temporarily mocked with a random image API service, such as [Picsum](https://picsum.photos/).
 - Front-ends must include all screens in the completed application and should closely match the clickable prototypes created previously, unless the team believes an alternate user experience is beneficial.
@@ -58,21 +31,12 @@ The following requirements outline what must be, must not be, and may be done du
 - You **must not** use [next.js](https://nextjs.org/) or any other server-side rendering framework.
 - You **must not** use the front-end frameworks [Material UI](https://material-ui.com/) or [Bootstrap](https://react-bootstrap.github.io/).
 - You **must not** hard-code any data in your front-end code that will eventually be provided by your application's back-end or other external source.
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30
 
 ## Grading
 
 Individuals will be graded, in part, according to...
 
 - individual code contributions, as visible through git logs - make sure you commit your own work!
-<<<<<<< HEAD
-- proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/Feature_branch_version_control_workflow)
-- the quality of the work
-- a well written and thorough [Product Backlog](https://knowledge.kitchen/Software_engineering_project_kickoff#Create_the_initial_product_backlog)
-- the [proper setup of a GitHub repository](https://knowledge.kitchen/Software_engineering_project_kickoff#Configure_GitHub_repository)
-- the proper setup and use of a [Sprint Task Board](https://knowledge.kitchen/GitHub_for_team_collaboration#Project_boards) to indicate the Sprint Backlog and accurate status of all of their work at all times during the Sprint
-=======
 - proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/feature-branch-workflow/)
 - the [proper setup and maintenance of a GitHub repository](./instructions-0c-project-setup.md)
 - the quality of the work as a whole
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30

instructions-2-back-end.md

@@ -1,52 +1,23 @@
 # Back-End Development
 
-<<<<<<< HEAD
-Each team must have completed and [demo'd](https://knowledge.kitchen/Scrum_development_framework#Demo_for_Stakeholders) the working back-end of their group project by the end of the corresponding Sprint.
-=======
 Each team must have completed and [demo'd](https://knowledge.kitchen/content/courses/agile-development-and-devops/scrum/stakeholder-demos/) the working back-end of their group project by the end of the corresponding Sprint.
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30
 
 ## Technical requirements
 
 ### Musts...
 
-<<<<<<< HEAD
-- All back-end code must be generated using **Express.js**.
-- All dynamic routes must be completed and must respond with meaningful JSON data.
-- All static routes must be completed and respond with the requested file.
-- The front-end must be updated to make requests to the back-end for all data and functionality. The two must be completely integrated by the end of this sprint.
-- Each developer must have written **unit tests** using the **mocha** and **chai** modules that provide at least 10% code coverage of the back-end code. Use the **istanbul nyc** module to verify code coverage.
-- Instructions on how to set up and run the project must be included in the README.md file in version control. It must be possible for anybody to follow the instructions on the README.md to build and run the project on their local machines.
-
-### Must nots...
-
-- Back-end templating frameworks, such as Pug, Mustache, Handlebars, EJS, etc, are forbidden.
-- Dynamic routes must not respond with React JSX, HTML, or anything but JSON data.
-- Integration with a database must not be attempted yet.
-
-### May...
-
-- Any account registration or log in functionality may be begun during this sprint, but only if all other back-end tasks have been completed. It is okay to ignore account registration for this sprint and begin work on it in the next sprint.
-=======
 - All back-end code **must** be generated using **Express.js**.
 - All dynamic routes **must** be completed and must respond with meaningful `JSON` data.
 - All static routes **must** be completed and respond with the requested file.
 - The front-end **must** be updated to make requests to the back-end for all data and functionality. The two **must** be completely integrated by the end of this sprint.
 - Each developer **must** have written **unit tests** using the **mocha** and **chai** modules that provide at least `10%` code coverage of the back-end code. Use the [c8](https://www.npmjs.com/package/c8) module to verify code coverage.
 - Instructions on how to set up and run the project **must** be included in the ` README.md`` file in version control. It **must** be possible for anybody to follow the instructions on the  `README.md` to build and run the project on their local machines.
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30
 
 ## Grading
 
 Individuals will be graded, in part, according to...
 
 - individual code contributions, as visible through git logs - make sure you commit your own work!
-<<<<<<< HEAD
-- proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/Feature_branch_version_control_workflow)
-- the quality of the work
-- the proper setup and use of a [Spring Task Board](https://knowledge.kitchen/GitHub_for_team_collaboration#Project_boards) to indicate the Sprint Backlog and accurate status of all of their work at all times during the Sprint
-=======
 - proper adherence to the [Feature Branch git workflow](https://knowledge.kitchen/content/courses/agile-development-and-devops/slides/feature-branch-workflow/)
 - the [proper setup and maintenance of a GitHub repository](./instructions-0c-project-setup.md)
 - the quality of the work as a whole
->>>>>>> 2b503b8d496e3059af152e2a078c2f0d478bcf30