update for updated planning-and-collaborating

planning/README.md

@@ -1,133 +0,0 @@
-# How to Plan
-
-1. [Brainstorming](#brainstorming)
-2. [Prioritizing](#prioritizing)
-3. [User Story Dependencies](#user-story-dependencies)
-4. [Acceptance Criteria](#acceptance-criteria)
-5. [Defining Tasks](#defining-tasks)
-6. [Project Board](#project-board)
-7. [Sprinting and Reviewing](#sprinting-and-reviewing)
-
----
-
-## Brainstorming
-
-> - What user needs and business problem does this app cover?
-> - Who is the user?
-> - What is the business?
-
----
-
-## Prioritizing
-
-> How to decide which stories to focus on.
-
-At this stage in planning your team will decide which stories are more aor less
-important. You will be writing your ideas into a _backlog_.
-
-- [Many Strategies](https://zapier.com/blog/how-to-prioritize)
-- The Priority Quadrant
-  - [The Quadrant](https://www.youtube.com/watch?v=NGvsxPOmWuw)
-  - [Problems with this method](https://www.linkedin.com/pulse/why-prioritization-impacteffort-doesnt-work-itamar-gilad)
-- Other Perspectives
-  - [Alex Ponomarev](https://medium.com/swlh/prioritizing-user-stories-in-agile-projects-d1dd8dd79165)
-  - [Michael Lant](https://michaellant.com/2010/05/21/how-to-easily-prioritize-your-agile-stories/)
-
----
-
-## Acceptance Criteria
-
-> How you'll know when a story is finished.
-
-Now that you have an idea what the project will eventually be like, it's time to
-get specific. Acceptance criteria are a way to scope and verify your user
-stories.
-
-> Given [context] when [a specific action is performed] then [a set of > > > > >
->
-> > consequences should occur]
-
-You can write your first-draft acceptance criteria in your backlog, later moving
-them under each user story in your `development-strategy.md`, and ultimately
-creating a checklist in each issue.
-
-- [Yodiz](https://www.yodiz.com/blog/user-stories-acceptance-definition-and-criteria-in-agile-methodologies/)
-- [Zepel](https://zepel.io/agile/acceptance-criteria-for-user-stories/)
-- [Ruby Garage](https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important)
-- [The Infinity Project](https://www.youtube.com/watch?v=KYS0ptJ4JWc)
-  1. User Input / User Action
-  2. Process
-  3. Results
-
----
-
-## User Story Dependencies
-
-> How to plan your development schedule.
-
-Some user stories depend on each other, some do not. Figuring out these
-relationships will make it possible go from a disorganized backlog to an
-organized development strategy.
-
-Understanding these dependencies can also allow you to develop much more
-efficiently. You can develope user stories that do not depend on each other in
-parallel instead of waiting for one to finish before moving on the next.
-
-Here are some questions you can ask yourself to help understand your project:
-
-- Do I need _A_ in order to be able to build _B_?
-- Can the user do B without A being available?
-
-A nice way to visualize these relationships is by creating a graph to visually
-represent dependencies:
-
-- [a quiz app](https://excalidraw.com/#json=5248906938023936,dnJz0Qy9tk5M4ho-RUiqYQ)
-- [a portfolio example](https://github.com/elewa-student/User-Centered-Development#story-dependencies)
-
-[Excalidraw](https://excalidraw.com/) is a great tool for collaboratively
-writing these diagrams.
-
----
-
-## Defining Tasks
-
-> How to break the story into coding tasks.
-
-Answering these questions is a way to break down complex user stories and to
-determine what code is needed. Following this questions guide will help you fill
-in the specifications of each step in your `development-strategy.md`
-
-Handlers are the glue of your user stories. Understanding your answers to these
-questions will not only help you decide which tasks to develop, but can be used
-to plan the details of the user story's handler:
-
-1. **User Story Objectives**
-   1. _... ?_
-2. **User Flow ?**
-   1. _... ?_
-3. **Wireframes ?**
-   1. _... ?_
-
-- [Lars Bilde](https://www.youtube.com/watch?v=gZ4uLafsxAk)
-- [Christiaan Verwijs](https://medium.com/the-liberators/10-powerful-strategies-for-breaking-down-user-stories-in-scrum-with-cheatsheet-2cd9aae7d0eb)
-
----
-
-## Project Board
-
-> How to manage your team's project
-
-Convert your development strategy into milestones (user stories), issues, labels
-and a project board. When you create the milestones for your user stories, you
-can include the _acceptance criteria_ as a checklist in the milestone's
-description.
-
-This isn't a permanent thing! You can always adjust the project board and
-development strategy as the project evolves; adding issues, removing issues,
-adjusting tasks ... whatever is necessary to make the project go smoothly.
-
----
-
-## Sprinting and Reviewing
-
-The fun part, writing code and closing issues ;)

planning/backlog.md

@@ -1,30 +0,0 @@
-# Backlog
-
-A collection of user stories you can choose from. Stories inside each priority
-level are not necessarily in order, it's up to your group to decide how they fit
-into your strategy. These are also just suggestion, feel free to change them or
-create your own!
-
-## Must-Haves
-
-> these are necessary for basic usability
-
-- [ ] As a ... I want to ... so that ...
-  - _Given [context] when [a specific action is performed] then [a set of
-    consequences should occur]_
-
-## Should-Haves
-
-> these will complete the user experience, but are not necessary
-
-- [ ] As a ... I want to ... so that ...
-  - _Given [context] when [a specific action is performed] then [a set of
-    consequences should occur]_
-
-## Could-Haves
-
-> would be really cool ... if there's time
-
-- [ ] As a ... I want to ... so that ...
-  - _Given [context] when [a specific action is performed] then [a set of
-    consequences should occur]_

planning/communication.md

@@ -1,51 +0,0 @@
-# Communication
-
-## Group Rules
-
-<!-- any general rules you'd like to set for your group? -->
-
----
-
-## Communication Schedule
-
-| Day | How | The topic of discussion |
-| --- | :-: | ----------------------- |
-|     |     |                         |
-
-## Communication Channels
-
-how often will we get in touch on each channel, and what we will discuss there:
-
-- **Issues**:
-- **Pull Requests**:
-- **GitHub Discussions**
-- **Slack/Discord**:
-- **Video Calls**:
-
----
-
-## Availability
-
-### Availability for calling/messaging
-
-| Day    | Monday  | Tuesday | Wednesday | Thursday | Friday  | Saturday | Sunday  |
-| ------ | :-----: | :-----: | :-------: | :------: | :-----: | :------: | :-----: |
-| _name_ | 13 - 20 | 13 - 20 |  13 - 20  | 13 - 20  | 13 - 20 | 13 - 20  | 13 - 20 |
-
-### How many hours everyone has per day
-
-- name: _5h_; extra comments?
-- name: _6h_;
-- name: _5h_;
-- name: _4h_;
-- name: _3h_;
-
-## Asking for Help
-
-There's a fine line between confidently learning from your mistakes, and
-stubbornly getting no where. Here is a general guide for when to ask for help
-based on how long you've been stuck on the same problem:
-
-1. _0 -> 30 min_: Try on your own
-2. _30 -> 60 min_: Ask your group for help
-3. _60+ min_: Tag your coaches in Slack or GitHub

planning/constraints.md

@@ -1,32 +0,0 @@
-# Constraints
-
-Some boundaries around our project.
-
-## External
-
-<!--
-  constraints coming from the outside that your team has no control over.
-  These may include:
-  - project deadlines
-  - UI design or color schemes
-  - technologies (sometimes a client will tell you what to use)
--->
-
-## Internal: Involuntary
-
-<!--
-  constraints that come from within your team, and you have no control over.
-  They may include:
-  - each of your individual skill levels
-  - amount of time available to work on the project
--->
-
-## Internal: Voluntary
-
-<!--
-  constraints that your team decided on to help scope the project. they may include:
-  - coding style & conventions
-  - agree on a code review checklist for the project repository
-  - the number of hours you want to spend working
-  - only using the colors black and white
--->

planning/development-strategy.md

@@ -1,55 +0,0 @@
-# Project Name
-
-<!-- describe your project -->
-
----
-
-## Setup
-
-<!-- what code do you need just to open the project? this might include:
-  - boilerplate code (https://brandlitic.com/what-is-boilerplate-code/)
-  - loading program data
-  - rendering the initial user interface
--->
-
----
-
-<!-- copy this section once for each must-have user story -->
-
-## user story
-
-<!-- each issue created from this section will have the `for: user story` label -->
-
-> "as a ... i can ... so that ..."
-
-<!-- write any extra notes or description -->
-
-<!-- describe the tasks to build this user story
-  these will have the `type: logic` label, for example
-  not all projects will have all types of tasks
-  and these are not the only possible types, just some suggestions
--->
-
-### Logic: user story
-
-- a _logic_ task -> this will become one issue
-  - [ ] some checkboxes for this task
-  - [ ] these will be copy-pasted into the issue
-
-### Interface: user story
-
-- an _interface_ task -> this will become one issue
-  - [ ] some checkboxes for this task
-  - [ ] these will be copy-pasted into the issue
-
-### Interaction: user story
-
-- an _interaction_ task -> this will become one issue
-  - [ ] some checkboxes for this task
-  - [ ] these will be copy-pasted into the issue
-
-### Documentation: user story
-
-- a _documentation_ task -> this will become one issue
-  - [ ] some checkboxes for this task
-  - [ ] these will be copy-pasted into the issue

planning/retrospective.md

@@ -1,21 +0,0 @@
-# Retrospective
-
-## Stop Doing
-
-## Continue Doing
-
-## Start Doing
-
-## Lessons Learned
-
----
-
-## Strategy vs. Board
-
-### What parts of your plan went as expected?
-
-### What parts of your plan did not work out?
-
-### Did you need to add things that weren't in your strategy?
-
-### Or remove extra steps?

planning/user-personas.md

@@ -1,18 +0,0 @@
-# User Personas
-
-<!-- some introduction -->
-
----
-
-<!-- a persona -->
-
-## Their Role
-
-- **Bio**:
-- **Needs/Goals**:
-- **Frustrations**:
-- **Scenario 1**:
-
----
-
-<!-- more personas ... -->