[SLUG] Transferring changes from Slug as of 2022-07-21 17:11:27 +0100.

README.md

@@ -1 +1,131 @@
+# Engineering Project I (Makersbnb)
 
+_Coaching this? Read the coach guidance
+[here.](https://github.com/makersacademy/slug/blob/main/materials/universe/engineering_projects/makersbnb/HOW_TO_COACH.x.md)_
+
+This week you will:
+
+* Learn to work and communicate effectively as part of a team to build a web application.
+* Learn to break down projects into tasks and assign them to pairs.
+* Learn to use agile ceremonies to organise your work and improve your processes.
+* Learn to use the developer workflow to plan, implement and peer-review features.
+
+<!-- OMITTED -->
+
+## Introduction
+
+Your coach will share the teams with you this morning. Once you have them, create a private slack channel with all team members and invite your coach to that channel.
+
+Get together on a Zoom call (or gather in front of the same screen) and watch this introduction video. 
+
+@TODO video intro
+
+<!-- OMITTED -->
+
+## Project Setup
+
+1. Create a private slack channel with all team members and invite the coach leading this
+   week to that channel.
+2. One member in your group should fork the seed repo for this project, and add the other
+   members of your group as collaborators. Everyone will pull and push to this fork.
+3. Add a link to this repo to the description of your team's slack channel.
+4. [Read the project specification together](./specification.md)
+5. Decide how you will work, by creating a small team charter — [here's a template you can
+   use](https://docs.google.com/document/d/1JbXksrTlu_-kCvq-ITzLucvFvv3QOFN9P_LsTRfQ3kM/edit).
+6. Create a Trello board for your project, [using this
+   template.](https://trello.com/invite/b/g9JBypiG/efd9585fe05fadab98ee0008be9df673/engineering-project-i-template)
+7. Start turning the headline specifications into user stories and create one Trello
+   ticket in the column "Backlog (all TODO)". 
+8. Get a break, and then start [your first sprint](#agile-sprints).
+
+## Agile Sprints and Ceremonies
+
+Agile software teams work in sprints. At the beginning of a new sprint, the team decides
+which features to work on in that sprint, and what to leave for later. This week, you will
+work with shorter sprints of roughly two days. Here is a suggested schedule:
+  * Monday to Tuesday - Sprint #1
+  * Wednesday to Thursday - Sprint #2
+  * Friday - Sprint #3
+  * Stand-up every morning (15 min) after your peer groups check-ins.
+  * Retro at the end of both sprints (and recommended at the end of each day of work).
+
+@TODO stand-up video?
+
+To start your first sprint:
+  1. Get together as a team.
+  2. Pick a few tickets from the tickets backlog, and move them to the "Current sprint"
+     column — remember your goal is to get them done within this first sprint, so it's
+     better to start with less initially. For this first sprint, pick tickets [relevant to
+     the MVP of your project only](#minimum-viable-product-mvp). You can always extend the
+     sprint with more tickets, if you find you're working faster than expected.
+  3. Assign the first tickets to pairs.
+  4. Get into your pairs, [watch this video](#developer-workflow), and start the work.
+
+@TODO demo videos of running a short sprint, and a short retro? 
+
+## Developer Workflow
+
+Watch this video with your pair _before_ starting to work your first ticket.
+
+@TODO video of coaches demonstrating developer workflow (pick a ticket -> test drive
+feature -> PR -> code review -> merge)
+
+[A description of the workflow is here](./pills/developer_workflow.md)
+
+## Minimum viable product (MVP)
+
+The smallest thing that implements the core idea. Think about what this is for Airbnb.
+Build those user stories first. This MVP will exclude most of the headline specification
+items in the spec.
+
+If your specification asks for a car, don't build the wheels in the first week, the doors
+in the second week, etc. The customer can't try it! Instead, build a skateboard in the
+first week.
+
+Aim to get to your MVP by the end of Tuesday.
+
+## Breaking down user stories into tasks
+
+Make sure each user story is small enough to be completable in less than half a day.
+
+Some items in the spec include more than one feature. e.g. "Any signed up user can list a
+new space". Break this into two user stories and prioritise the one that gets you as close
+as possible to a product.
+
+Use the customer's language (the domain language) in the user stories. Most words in the
+user stories should appear in the spec.
+
+Avoid splitting the work on the different "layers" of the program (e.g one pair working on the HTML view and one pair working on the Sinatra code). When working on a user story, you will have to work on all
+these different components — [a feature will involve work on all the different layers of
+your web application.](https://www.visual-paradigm.com/scrum/user-story-splitting-vertical-slice-vs-horizontal-slice/#:~:text=layers%20as%20possible.-,Vertical%20Slice%20vs%20Horizontal%20Slice,-A%20user%20story)
+
+## Things to watch out for
+
+* **Working overtime** — make sure your take breaks and swap pairs regularly. It's easy to
+  get lost in the work and stretch yourself, but remember that this week's goal is also to
+  learn how to work effectively. A team that is exhausted is not a great team to work in!
+* **Rushing to get things done** - releasing features is important, but you shouldn't
+  sacrifice your process in order to rush ahead. It's often better to start slow, and
+  invest more time into deep learning and having strong processes and communication, so it
+  pays off on the long run.
+* **Sidelining testing** - more than ever, TDD and other software engineering practices
+  you've learned so far will be important this week. Make sure that you don't skip over
+  them. They will slow you down a bit at first, but it will pay off on the long run. If
+  you din't they're slowing you down _too much_, maybe there is something to correct in
+  your process — your coach can support with this.
+* **Everyone's voice isn't heard** - it's important that everyone in the team gets their
+  say on the project and how the team works, and that everyone feels like they can
+  contribute, even if you're at different technical levels. If you feel that something
+  isn't quite right, stand-ups or retros are a good place to raise it, in order to get the
+  team to a better place. If you're not sure how to approach it, get in touch with your
+  coach so they can support.
+
+<!-- BEGIN GENERATED SECTION DO NOT EDIT -->
+
+---
+
+**How was this resource?**  
+[😫](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=README.md&prefill_Sentiment=😫) [😕](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=README.md&prefill_Sentiment=😕) [😐](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=README.md&prefill_Sentiment=😐) [🙂](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=README.md&prefill_Sentiment=🙂) [😀](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=README.md&prefill_Sentiment=😀)  
+Click an emoji to tell us.
+
+<!-- END GENERATED SECTION DO NOT EDIT -->

pills/developer_workflow.md

@@ -0,0 +1,116 @@
+# Git and Github Developer Workflow
+
+@TODO video of coaches demonstrating developer workflow 
+
+## 1. Pick a task
+
+Before anything else, create a new branch locally to work on it.
+
+```bash
+# Make sure you're on main
+# with the latest changes on main
+# (this will help to avoid conflicts later on).
+git checkout main
+git pull origin main
+
+# Create a new branch (branching out from main).
+# Make sure the branch name is descriptive of the 
+# task, bug or feature you're working on.
+git checkout -b new-feature-calendar
+```
+
+## 2. Test-drive and Implement the feature
+
+Then commit your work, and push the branch:
+
+```bash
+git add .
+
+# Make sure the commit message is descriptive
+# of the changes (so it's easier to find it later).
+git commit -m "Implement the calendar feature on the booking page"
+
+git push -u origin new-feature-calendar
+```
+
+## 3. Open a pull request
+
+_The guidance below is for the developers who implemented the changes, and will open the PR - the PR's owners._
+
+A pull request (PR), also called a _diff_, is a way to list all the changes you made on
+your branch that are not on the `main` branch yet. By reviewing these changes, your team
+is able to see what will get merged in the main branch, and have the opportunity to review
+it and make suggestions to improve the code before it gets merged.
+
+Make sure your PR's title and description contains enough details for someone else who's
+not familiar with the code to review. Once the PR is created, send the link to your team.
+
+## 4. Someone else reviews the PR
+
+_The guidance below is for the developer who will review the PR._
+
+A code review is usually a task done alone. This is because reviewing code takes a lot of
+cognitive effort, so it's important to focus on the code and make note of anything you
+feel should be changed.
+
+Avoid suggesting too many things — focus on offering feedback to _improve_ the PR, by
+pointing out a couple of changes you feel would be important (code readability, OOP and
+design, improve the tests...), but also offer _validation_ feedback on something you think
+was done really well.
+
+When suggesting changes, try to tie it to the software engineering practices you've
+learned and used so far, and make sure it will be useful to the PR's owner to improve the
+code. Make it an observation, rather than a judgement, and always leave the room for
+discussion in your feedback.
+
+## 5. The PR owner will make changes based on the feedback
+
+```bash
+# Implement the changes and commit them.
+git add .
+git commit -m "Changed the method name based on PR feedback"
+git push origin new-feature-calendar 
+```
+
+## 6. The PR is merged
+
+Merging the PR on Github means the branch is merged into `main` by Github on the central
+repository. The task is done.
+
+After this, make sure everyone pulls the latest version of `main`, before starting a new
+branch.
+
+```bash
+git checkout main
+
+git pull origin main
+```
+
+If you're already working on another branch, it's also good, before opening a PR, to merge
+the latest `main` _into your branch_. This reduces the potential amount of changes between
+your branch and `main`, and avoids having too many conflicts when opening a PR.
+
+```bash
+# On your feature branch.
+git checkout new-feature-calendar
+
+# Fetching and merging the latest main
+# into your feature branch.
+git fetch
+git merge origin/main
+
+# Push your feature branch.
+git push origin new-feature-calendar
+```
+
+
+
+<!-- BEGIN GENERATED SECTION DO NOT EDIT -->
+
+---
+
+**How was this resource?**  
+[😫](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/developer_workflow.md&prefill_Sentiment=😫) [😕](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/developer_workflow.md&prefill_Sentiment=😕) [😐](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/developer_workflow.md&prefill_Sentiment=😐) [🙂](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/developer_workflow.md&prefill_Sentiment=🙂) [😀](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/developer_workflow.md&prefill_Sentiment=😀)  
+Click an emoji to tell us.
+
+<!-- END GENERATED SECTION DO NOT EDIT -->

pills/how_to_run_retro.md

@@ -0,0 +1,11 @@
+# How to run a Team Retro
+
+<!-- BEGIN GENERATED SECTION DO NOT EDIT -->
+
+---
+
+**How was this resource?**  
+[😫](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/how_to_run_retro.md&prefill_Sentiment=😫) [😕](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/how_to_run_retro.md&prefill_Sentiment=😕) [😐](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/how_to_run_retro.md&prefill_Sentiment=😐) [🙂](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/how_to_run_retro.md&prefill_Sentiment=🙂) [😀](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/how_to_run_retro.md&prefill_Sentiment=😀)  
+Click an emoji to tell us.
+
+<!-- END GENERATED SECTION DO NOT EDIT -->

pills/how_to_run_standup.md

@@ -0,0 +1,11 @@
+# How to run a Team Stand-up
+
+<!-- BEGIN GENERATED SECTION DO NOT EDIT -->
+
+---
+
+**How was this resource?**  
+[😫](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/how_to_run_standup.md&prefill_Sentiment=😫) [😕](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/how_to_run_standup.md&prefill_Sentiment=😕) [😐](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/how_to_run_standup.md&prefill_Sentiment=😐) [🙂](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/how_to_run_standup.md&prefill_Sentiment=🙂) [😀](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=pills/how_to_run_standup.md&prefill_Sentiment=😀)  
+Click an emoji to tell us.
+
+<!-- END GENERATED SECTION DO NOT EDIT -->

specification.md

@@ -0,0 +1,46 @@
+# Project specification
+
+We would like a web application that allows users to list spaces they have available, and to hire spaces for the night.
+
+### Headline specifications
+
+- Any signed-up user can list a new space.
+- Users can list multiple spaces.
+- Users should be able to name their space, provide a short description of the space, and a price per night.
+- Users should be able to offer a range of dates where their space is available.
+- Any signed-up user can request to hire any space for one night, and this should be approved by the user that owns that space.
+- Nights for which a space has already been booked should not be available for users to book that space.
+- Until a user has confirmed a booking request, that space can still be booked for that night.
+
+### Nice-to-haves
+
+- Users should receive an email whenever one of the following happens:
+ - They sign up
+ - They create a space
+ - They update a space
+ - A user requests to book their space
+ - They confirm a request
+ - They request to book a space
+ - Their request to book a space is confirmed
+ - Their request to book a space is denied
+- Users should receive a text message to a provided number whenever one of the following happens:
+ - A user requests to book their space
+ - Their request to book a space is confirmed
+ - Their request to book a space is denied
+- A ‘chat’ functionality once a space has been booked, allowing users whose space-booking request has been confirmed to chat with the user that owns that space
+- Basic payment implementation though Stripe.
+
+### Mockups
+
+Mockups for MakersBnB are available [here](./MakersBnB_mockups.pdf).
+
+
+<!-- BEGIN GENERATED SECTION DO NOT EDIT -->
+
+---
+
+**How was this resource?**  
+[😫](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=specification.md&prefill_Sentiment=😫) [😕](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=specification.md&prefill_Sentiment=😕) [😐](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=specification.md&prefill_Sentiment=😐) [🙂](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=specification.md&prefill_Sentiment=🙂) [😀](https://airtable.com/shrUJ3t7KLMqVRFKR?prefill_Repository=makersacademy/engineering-project-1&prefill_File=specification.md&prefill_Sentiment=😀)  
+Click an emoji to tell us.
+
+<!-- END GENERATED SECTION DO NOT EDIT -->