simplifications

instructions-0a-app-map-wireframes.md

@@ -8,12 +8,11 @@ All team members must use the same software. Use any software of your team's cho
 
 - The free trial of [Figma](https://www.figma.com/) is a fantastic cross-platform web app or desktop app for teams that want more commercial-quality tools.
 - [draw.io](https://draw.io) is recommended for all teams on any platform. It is always free and works wonderfully on the web or as a desktop app.
-- Do not use any Adobe products for this exercise.
 
 Both Figma and draw.io have extensions for Visual Studio Code that, while not a replacement for either app, may be useful for some tasks:
 
-- [Figma x VS Code](https://marketplace.visualstudio.com/items?itemName=idered.figma)
-- [Draw.io VSCode Integration](https://marketplace.visualstudio.com/items?itemName=hediet.vscode-drawio)
+- [Figma VS Code extension](https://marketplace.visualstudio.com/items?itemName=figma.figma-vscode-extension)
+- [Draw.io VSCode extension](https://marketplace.visualstudio.com/items?itemName=hediet.vscode-drawio)
 
 ## Wireframe requirements
 
@@ -44,7 +43,7 @@ In this scenario, you would design wireframe diagrams for each of the Dashboard,
 
 ### Diagram widths
 
-All wireframe diagrams must have exactly the same width... heights can vary as necessary.
+All wireframe diagrams must have exactly the same width... heights can vary as necessary to fit the content.
 
 ### Consistency
 

instructions-0b-prototyping.md

@@ -8,7 +8,7 @@ Use [Figma's prototyping](https://www.figma.com/prototyping/) functionality to b
 
 ## Prototype requirements
 
-- all buttons, links or other user interface components that allow a user to transition from one screen to another must be functional in the prototype
+- **all** buttons, links or other user interface components that allow a user to transition from one screen to another must be functional in the prototype
 - any user interface components that show a dynamic overlay panel when clicked or tapped must be functional in the prototype.
 - you may need to create new variations of your existing wireframe diagrams in order to make the prototype look more "believable" - create as many as necessary to give a real sense of how the application flow might work.
 - your prototypes must be designed to clearly show the way in which a user navigates from one screen to another, as well as how they solve the core use cases and needs your app is designed to solve.

instructions-0c-project-setup.md

@@ -18,11 +18,11 @@ Discord is each team's primary communication tool. Each member's communications
 
 Each team **must have at least one Discord channel** where the professor, and any course assistants, graders, and tutors are also invited to be members:
 
+Channel names must be short and consistent. For example, if a team is named `octopus`, their main channel should be called `team-octopus`
+
 - use this channel for general team communication
 - individual participation in this and other channels may be used towards each member's grade
 
-Channel names must be short and consistent. For example, if a team is named `octopus`, their main channel might be called `team-octopus`
-
 ### Private communications channels
 
 Communications within private channels or on communications systems where the stakeholders are not present are not visible to stakeholders and therefore will not be considered analyzing the engagement of any individual or of the team as a whole.
@@ -31,7 +31,7 @@ Communications within private channels or on communications systems where the st
 
 In order to allow your managers to track your individual contribution to the project, it is imperative that you use the same username for both `git` on your local computer, where you will be making commits, and `GitHub`, where you will be doing pull requests.
 
-To set your `git` username locally:
+To set your `git` username locally... change `'monalisa'` in the example to your own username:
 
 ```bash
 git config --global user.name "monalisa"

instructions-0d-sprint-planning.md

@@ -13,7 +13,7 @@ View a [video overview of creating the Sprint Backlog in GitHub](https://youtu.b
 Each User Story added to the Sprint Backlog must...
 
 - 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)
-- be assigned the `Sprint N` Milestone, where N is the number of the current sprint, in GitHub's Issue tracker
+- 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, 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

instructions-1-front-end.md

@@ -12,25 +12,25 @@ The following requirements outline what must be, must not be, and may be done du
 - All component definitions must be written as **functions**, not as classes.
 - All component content must be written using **JSX**, not only plain Javascript.
 - 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.
-- Any front-end dynamic functionality, such as buttons that change something on the screen when clicked, or search fields that filter results as they are typed into, must be implemented in the front-end using mock data.
-- 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.
+- Any front-end dynamic functionality, such as buttons that change something on the screen when clicked, or search fields that filter results as they are typed into, must be implemented in the front-end.
+- If your app will eventually have user registration and login functionality, all front-end screens to support this must be created, although they can 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...
+### May...
 
-- State managers, such as [Redux](https://react-redux.js.org/) or [Mobx](https://mobx.js.org/README.html#introduction), must not be used. However, you are welcome and encouraged to use [React Context](https://react.dev/learn/passing-data-deeply-with-context) for sharing state among multiple components.
-- 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.
+- You **may** use [React Context](https://react.dev/learn/passing-data-deeply-with-context) for sharing state among multiple components.
+- You **may** use the front-end framework, [Tailwind](https://tailwindcss.com/) to streamline your CSS styling.
+- You **may** use [mockaroo](https://mockaroo.com/mock_apis), [picsum](https://picsum.photos/) and [other mocking/faking tools](https://www.npmjs.com/search?q=fake%20data) to mock any data that will eventually come from your application's back-end or other external source.
 
-### May...
+### Must nots...
 
-- You may use front-end design frameworks, such as [Tailwind](https://tailwindcss.com/), [Material UI](https://material-ui.com/), or [Bootstrap for React](https://react-bootstrap.github.io/).
-- 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/content/courses/web-design/navigation/#global-navigation-aka-primary-navigation).
+- You **must not** any 3rd-party state manager tools, such as [Redux](https://react-redux.js.org/) or [Mobx](https://mobx.js.org/README.html#introduction)
+- 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.
 
 ## Grading
 
@@ -39,4 +39,4 @@ Individuals will be graded, in part, according to...
 - individual code contributions, as visible through git logs - make sure you commit your own work!
 - 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
+- the quality of the work as a whole

instructions-2-back-end.md

@@ -6,22 +6,12 @@ Each team must have completed and [demo'd](https://knowledge.kitchen/content/cou
 
 ### Musts...
 
-- 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.
 
 ## Grading
 
@@ -30,4 +20,4 @@ Individuals will be graded, in part, according to...
 - individual code contributions, as visible through git logs - make sure you commit your own work!
 - 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
+- the quality of the work as a whole

instructions-3-database.md

@@ -6,20 +6,16 @@ Each team must have completed and [demo'd](https://knowledge.kitchen/content/cou
 
 ### Musts...
 
-- A MongoDB database hosted on a [free MongoDB Atlas](https://www.mongodb.com/cloud/atlas) instance must be used to store all dynamic data of the app.
-- The database must be integrated into the Express.js back-end code using [mongoose](https://mongoosejs.com/).
-- Any credentials used to log into a database or other remote service must be stored in a hidden file called `.env` that is excluded from version control by adding it to your .gitignore file. Load these credentials from environmental variables into your project using the [dotenv](https://github.com/motdotla/dotenv) module.
-- When receiving data from the front-end to store into the database, always do data validation before sending that data to the database. Use the [express-validator](https://express-validator.github.io/docs/) module, or something similar to perform data validation prior to sending any data originating from the request to the database.
+- A MongoDB database hosted on a [free MongoDB Atlas](https://www.mongodb.com/cloud/atlas) instance **must** be used to store all dynamic data of the app.
+- The database **must** be integrated into the Express.js back-end code using [mongoose](https://mongoosejs.com/).
+- Any credentials used to log into a database or other remote service **must** be stored in a hidden file called `.env` that is excluded from version control by adding it to your .gitignore file. Load these credentials from environmental variables into your project using the [dotenv](https://github.com/motdotla/dotenv) module.
+- Any account registration or log in functionality required by an app **must** use **JSON Web Tokens** (JWT) to validate authorization.
+- When receiving data from the front-end to store into the database, the back-end **must** do data validation before sending that data to the database. Use the [express-validator](https://express-validator.github.io/docs/) module or something similar to perform data validation prior to sending any data originating from the request to the database.
 
 ### Must nots...
 
-- Do not host a MongoDB instance locally on your own machine, unless you plan to be working offline for extended periods of time.
-- You are forbidden from storing any credentials used by your app to log into remote services, such as MongoDB or 3rd-party APIs in version control.
-- You are forbidden from using **HTTP Basic Authentication** or session-based authentication for any account registration or log in functionality your app requires.
-
-### May...
-
-- Any account registration or log in functionality required by an app must use **JSON Web Tokens** (JWT) to validate authorization.
+- You **must not** host a MongoDB instance locally on your own machine, unless you must work offline for extended periods of time.
+- You **must not** store any credentials used by your app to log into remote services, such as MongoDB or 3rd-party APIs, in version control.
 
 ## Grading
 
@@ -28,4 +24,4 @@ Individuals will be graded, in part, according to...
 - individual code contributions, as visible through [git logs](https://github.com/bloombar/git-developer-contribution-analysis) - make sure you commit your own work!
 - 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
+- the quality of the work as a whole

instructions-4-deployment.md

@@ -6,7 +6,7 @@ Each team must deploy their completed software applications to a [Digital Ocean
 
 - Credentials for logging into databases, APIs, or other remote services, must never be shared in version control. They are usually stored in private settings files, such as `.env` or similar, which are not included in the version control repository.
 - Each project must deploy their application front-and-back-ends using Digital Ocean. Use the Digital Ocean referral link shared by the instructor, which should grant you far more than enough credits to use Digital Ocean without cost.
-- Submit a link to your front-end code live on the web, and include that link on your README.md document.
+- Submit a link to your front-end code live on the web, and include that link on your `README.md` document.
 
 ## Extra credit opportunities
 
@@ -23,4 +23,4 @@ Individuals will be graded, in part, according to...
 - individual code contributions, as visible through [git logs](https://github.com/bloombar/git-developer-contribution-analysis) - make sure you commit your own work!
 - 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
+- the quality of the work as a whole