| Do | -Don’t | -||
|---|---|---|---|
| + |
This is an introductory stem:
| + + |
This is an introductory stem:
|
| Do | -Don’t | -||
|---|---|---|---|
| + |
| + + |
|
| Do | -Don’t | +
|---|
| + |
This is an introductory stem:
| + + |
This is an introductory stem:
|
|---|
| Do | -Don’t | +
|---|
| + |
These are just words in a list:
| + + |
These are just words in a list:
|
|---|
| Do | -Don’t | +
|---|
| + |
| + + |
|
|---|
| Do | -Don’t | -||
|---|---|---|---|
| + |
A project is where you:
| + + |
A project is where you:
|
+```
+
+**Image Folder**
+
+Each Topic needs to point to an image folder where image\(s\) are being used. The word `image_folder` should be in a markdown `h1` tag like below:
+
+```text
+# image_folder
+/Topic_Postman/
+```
+
+**Modules**
+
+Each Topic has modules. To add modules to a topic, add the module's `github_ids` in a list. Add the word `modules` in a markdown `h1` tag and then add the `github_id`s in a list with \*'s:
+
+```text
+# modules
+* 5
+```
+
+**Topic README Example**
+
+```text
+# github_id
+1
+
+# name
+Postman Topic
+
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+
+# image
+
+
+# image_folder
+/Topic_Postman/
+
+# modules
+* 5
+```
+
+#### Module README Format
+
+**Github ID**
+
+Each module needs a `github_id` so that the server knows it is unique. The word `github_id` should be in a markdown `h1` tag like below:
+
+```text
+# github_id
+1
+```
+
+**Name**
+
+Each Module needs a `name` field. The word `name` should be in markdown `h1` tag like below:
+
+```text
+# name
+Some Module 2
+```
+
+**Description**
+
+Each Module needs a `description` field to describe what the module will help accomplish. The word `description` should be in markdown `h1` tag like below:
+
+```text
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+```
+
+**Gems Needed**
+
+Each Module needs a `gems_needed` field which is the number of gems needed to unlock the module. The word `gems_needed` should be in markdown `h1` tag like below:
+
+**Note: Set it as 0 for now**
+
+```text
+# gems_needed
+0
+```
+
+**Image**
+
+Each Module needs an image field that visually represents the theme of the module.. The word `image` should be in markdown `h1` tag while the image `url` should be put in an `img` tag:
+
+```text
+# image
+
+```
+
+**Image Folder**
+
+Each Module needs to point to an image folder where the image is being used. The word `image_folder` should be in a markdown `h1` tag like below:
+
+```text
+# image_folder
+Topic_1/Module2_test/
+```
+
+**Final Example**
+
+```text
+# github_id
+1
+
+# name
+Some Module 2
+
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+
+# gems_needed
+ 0
+
+# image
+
+
+# image_folder
+Topic_1/Module2_test/
+```
+
+#### Activity/Lab README Format
+
+**Github ID**
+
+Each Activity/Lab needs a `github_id` so that the server knows it is unique. The word `github_id` should be in a markdown `h1` tag like below:
+
+```text
+# github_id
+1
+```
+
+**Name**
+
+Each Activity/Lab needs a `name` field. The word `name` should be in markdown `h1` tag like below:
+
+```text
+# name
+Some Activity
+```
+
+**Description**
+
+Each Module needs a `description` field to describe what the module will help accomplish. The word `description` should be in markdown `h1` tag like below:
+
+```text
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip.
+```
+
+**Summary**
+
+Each Activity/Lab has a `summary` field to describe what the activity will help accomplish **in more detail**. The word `summary` should be in markdown `h1` tag like below:
+
+```text
+# summary
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+```
+
+**Difficulty**
+
+Each Activity/Lab needs a `difficulty` field to indicate how hard the Activity/Lab is for the user. Add the word `difficulty` in a markdown `h1` tag, and put the difficulty under it:
+
+There are 3 types of `difficulty`:
+
+* Hard
+* Medium
+* Easy
+
+```text
+# difficulty
+Hard
+```
+
+**Image**
+
+Each Activity/Lab needs an `image` field that visually represents the theme of the module.. The word `image` should be in markdown `h1` tag while the image `url` should be put in an `img` tag:
+
+```text
+# image
+
+```
+
+**Image Folder**
+
+Each Activity/Lab needs to point to an image folder where the image is being used. The word `image_folder` should be in a markdown `h1` tag like below:
+
+```text
+# image_folder
+Topic1/Module2_test/Activity_4/
+```
+
+**Cards**
+
+The `cards` fields is used to indicate: the name of the card, the order in which the card will be shown, as well as the number of gems that the card is worth.
+
+* **Cards**
+
+To define cards in an Activity, you have to have the word `cards` in a markdown `h1` tag. This is used to tell the server where the cards are:
+
+```text
+# cards
+```
+
+* **Card Key**
+
+Each card you define in the Activity README must have a corresponding filename as its key. For example if a card/hint was named 1.md then its key would be 1. The card key must be placed in a markdown `h2` tag like below:
+
+```text
+## 1
+```
+
+* **Card Name**
+
+Each card has a `name` field. Each name should be in a markdown `h3` tag like below:
+
+```text
+### name
+Card 1 Github
+```
+
+* **Card Order**
+
+Each card has an order field. The order is the last digit of the card key. If a card had a key of 1-2, then the order for that card would be 2. Each `order` should be in a markdown h3 tag like below:
+
+```text
+### order
+2
+```
+
+* **Card Gems**
+
+Each card has a `gems` field. The gems fields is used to indicate the number of gems earned when opening a card. If this for a medium/easy card, this field is for the amount of gems a student would **lose** for using the medium/easy card. Each name should be in a markdown `h3` tag like below:
+
+```text
+### gems
+300
+```
+
+* **Card Concepts \(Only applies to Hard Cards\)**
+
+To give a card concepts, write the word `concepts` in a markdown `h3` tag and list out the name of the concepts using an \* like below:
+
+```text
+### concepts
+* concept_1.md
+* concept_2.md
+```
+
+> Note: When defining the cards, please put them in order of difficulty. Hard cards should be defined first, Medium cards next, and last easy cards. Below is an example:
+
+```text
+# cards
+
+## 1
+
+### name
+Bleh Card 1 Github
+
+### order
+1
+
+### gems
+300
+
+### concepts
+* concept_1.md
+* concept_2.md
+
+## 2
+
+### name
+Bleh Card 2 Github
+
+### order
+2
+
+### gems
+300
+
+## 1-1
+
+### name
+Bleh Card 2 Github
+
+### order
+1
+
+### gems
+300
+
+## 2-1
+
+### name
+Bleh Card 4 Github
+
+### order
+1
+
+### gems
+300
+
+## 1-1-1
+
+### name
+Bleh Card 3 Github
+
+### order
+1
+
+### gems
+300
+
+## 1-2-1
+
+### name
+Bleh Card 4 Github
+
+### order
+1
+
+### gems
+300
+
+## 2-1-1
+
+### name
+Bleh Card 131 Github
+
+### order
+1
+
+### gems
+300
+```
+
+**Final Example**
+
+```text
+# github_id
+19
+
+# name
+Some Activity
+
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip.
+
+# summary
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+
+# difficulty
+Hard
+
+# image
+
+
+# image_folder
+Topic1/Module2_test/Activity_4/
+
+# cards
+
+## 1
+
+### name
+Card 1 Github
+
+### order
+2
+
+### gems
+300
+
+## 1-1
+
+### name
+Medium Card
+
+### order
+1
+
+### gems
+100
+```
+
+#### Hint README Format \(Medium/Easy Cards\)
+
+**Image Folder**
+
+Each Hint needs to point to an image folder.
+
+```text
+# image_folder
+Topic1/Module2_test/Activity_7/cards
+```
+
+**Start of the Steps**
+
+You must include the word `steps` in a markdown `h1` tag so the server knows when the actual steps of the hints start like below:
+
+```text
+# steps
+```
+
+**Step Key**
+
+Next you **must** include the step key so the server can keep track of the individual steps. The Step key should be the hint/card name along with the step number in a markdown `h1` tag like this:
+
+```text
+## 1-2-1 Step 1
+```
+
+**Step Name**
+
+Under the hint name, you have to give the step a name with a markdown `h2` tag. **Please put the contents of name in a code block.** It should look something like this:
+
+```text
+### name
+How to install VSCode
+```
+
+**MD Content \(You need to include this for each step\)**
+
+To include the actual content for the step, include the `md_content` with a markdown `h2` tag. **Please put the contents of md\_content in a code block.** It should look something like this:
+
+```text
+### md_content
+Hello world in js. This is how you do it
+```
+
+**Optional Fields**
+
+* **Code Snippet**
+
+To include a code snippet for the step, include the `code_snippet` with a markdown `h2` tag. **Please put the contents of the code in a code block.** It should look something like this:
+
+```text
+### code_snippet
+def pls_work(): return True... maybe
+```
+
+* **Image**
+
+To include an image for a step, you need to put a `h2` markdown tag and assign it to `image`
+
+```text
+### image
+
+```
+
+**Final Example:**
+
+Note: You can always add more steps as long as you follow the above syntax.
+
+```text
+# image_folder
+Topic1/Module2_test/Activity_7/cards
+
+# steps
+
+## 1-2-1 Step 1
+
+### name
+How to install VSCode
+
+### md_content
+Hello world in js. This is how you do it
+
+### code_snippet
+def pls_work(): return True... maybe
+
+### image
+
+```
+
+#### Concept README Format
+
+**Concept Name**
+
+Each concept needs a `name`.
+
+```text
+# concept_name
+Concept name
+```
+
+**Image Folder**
+
+Each Concept needs to point to an image folder.
+
+```text
+# image_folder
+Topic1/Module2_test/concepts/
+```
+
+**Step Key**
+
+Next you **must** include the step key.
+
+```text
+# concept_name Step 1
+```
+
+**Step Name**
+
+Under the hint name, you have to give the step a name with a markdown `h2` tag.
+
+```text
+## name
+How to install VSCode
+```
+
+**MD Content**
+
+Include `md_content` as below:
+
+```text
+## md_content
+Hello world in js. This is how you do it.
+```
+
+**Optional Fields**
+
+* **Code Snippet**
+
+Include `code_snippet` like below:
+
+```text
+## code_snippet
+def pls_work(): return True... maybe
+```
+
+* **Image**
+
+Include an `image` like below:
+
+```text
+## image
+
+```
+
+* **Final Example:**
+
+Note: You can always add more steps as long as you follow the above syntax.
+
+```text
+# concept_name
+Concept name
+
+# image_folder
+Topic1/Module2_test/concepts/
+
+# 1-2-1 Step 1
+
+## name
+How to install VSCode
+
+## md_content
+Hello world in js. This is how you do it
+
+## code_snippet
+def pls_work(): return True... maybe
+
+## image
+
+```
+
+#### Checkpoint README Format
+
+**Filename**
+
+For the file name, name it the card that you want it to be associated with. So if you wanted to create a checkpoint for 1.md, you would name the checkpoint file `1-checkpoint.md`
+
+**Name**
+
+Every checkpoint needs a `name`:
+
+```text
+# name
+Code Check in
+```
+
+**Cards Folder**
+
+Every checkpoint needs a `cards_folder`:
+
+```text
+# cards_folder
+Topic1/Module7/Activity_13/cards/
+```
+
+**Checkpoint Type**
+
+This is to define the type of checkpoint. Put `checkpoint_type` in a markdown `h1` tag.
+
+Checkpoints could be **ONE** of the following:
+
+* Video
+* Image
+* Short Answer
+* Multiple Choice
+* Autograder
+
+```text
+# checkpoint_type
+Video
+```
+
+**Instruction**
+
+This is what you would tell the user to do for a checkpoint. Put the word `instruction` in a markdown `h1` tag. Put the instruction content under the `h1` tag like so:
+
+```text
+# instruction
+Submit a photo your Minsweeper code working
+```
+
+**Other Fields**
+
+* **Criteria \(Required for Video and Image Checkpoints Only\)**
+
+Criteria correspond to a rubric for TAs to grade a student's Image or Video Checkpoint.
+
+You must declare where the criteria for a checkpoint would begin. You would do this by putting the word `criteria` in a markdown `h1` tag like so:
+
+```text
+# criteria
+```
+
+After that you can list each criteria in a markdown `h2` tag with a number at the end like so:
+
+```text
+## criteria_1
+Does the student's board look like this:
+```
+
+* **Multiple Choice \(Only for MC Checkpoints\)**
+
+You must declare where the choices for the checkpoint would begin. You would do this by putting the words `mc_choices` in a markdown `h1` tag like so:
+
+```text
+# mc_choices
+```
+
+Next you would define each choice in a markdown `h2` tag with a number at the end like so:
+
+```text
+## choice_1
+```
+
+* **Files to send \(Autograder Checkpoint Only\)**
+
+These are the files that the student will submit if the student chooses to submit through their code to the `cli`.
+
+```text
+# files_to_send
+main.py class1.py class2.py
+```
+
+**Test file location \(Autograder Checkpoint Only\)**
+
+This field is used to tell where the test case folder is for the checkpoint.
+
+```text
+# test_file_location
+Topic1/Module7/Activity_13/Tests/test_1
+```
+
+#### Checkpoint Examples
+
+**Video/Image**
+
+```text
+# name
+Code Check in
+
+# cards_folder
+Topic1/Module7/Activity_13/Cards/
+
+# checkpoint_type
+Video
+
+# instruction
+Submit a photo your Minsweeper code working
+
+# criteria
+
+## criteria_1
+Does the student's board look like this?
+
+## criteria_2
+Does the student's code print the board out?
+```
+
+**Short Answer**
+
+```text
+# name
+Print Statements Short Answer
+
+# cards_folder
+Topic1/Module7/Activity_13/Cards/
+
+# checkpoint_type
+Short Answer
+
+# instruction
+Submit a photo your Minsweeper code working
+```
+
+**Multiple Choice**
+
+```text
+# name
+Print Statement Multiple Choice
+
+# cards_folder
+Topic1/Module7/Activity_13/Cards/
+
+# checkpoint_type
+Multiple Choice
+
+# instruction
+Which of the following choices is the correct way to use a print statement in python
+
+# mc_choices
+
+## choice_1
+console.log()
+
+## choice_2
+print()
+
+## choice_3
+printf()
+
+# correct_choice
+print()
+```
+
+**Autograder**
+
+```text
+# name
+Autograder Checkpoint
+
+# cards_folder
+Topic1/Module7/Activity_13/Cards/
+
+# checkpoint_type
+Autograder
+
+# instruction
+Do this
+
+# files_to_send
+main.py class1.py class2.py
+
+# test_file_location
+Topic1/Module7/Activity_13/Tests/test_1
+```
+
+#### Test Cases README Format
+
+> Note: All test case files must end with .test
+
+**File formatting**
+
+If you have multiple test cases they should have a number at the end of their filenames like below:
+
+**Your test case must be named after the lab/activity and then contain a number in sequential order:**
+
+* minesweeper1.test
+* minesweeper2.test
+* minesweeper3.test
+
+If you have input files, then make sure that their name has a .txt extension. **They should be in numerical order as like this**:
+
+* input1.txt
+* input2.txt
+* input3.txt
+
+**Name**
+
+Each test case file must have a `name`:
+
+```text
+Board Function
+>>> main(2)
+Mines: 10
+ 0123456789
+0 XXXXXXXXXX 0
+1 XXXXXXXXXX 1
+2 XXXXXXXXXX 2
+3 XXXXXXXXXX 3
+4 XXXXXXXXXX 4
+5 XXXXXXXXXX 5
+6 XXXXXXXXXX 6
+7 XXXXXXXXXX 7
+8 XXXXXXXXXX 8
+9 XXXXXXXXXX 9
+ 0123456789
+Enter your move (for help enter "H"): 42
+Mines: 10
+ 0123456789
+0 XXXXXXXXXX 0
+1 XXXXXXXXXX 1
+2 XXXXMXXXXX 2
+3 XXXXXXXXXX 3
+4 XXXXXXXXXX 4
+5 XXXXXXXXXX 5
+6 XXXXXXXXXX 6
+7 XXXXXXXXXX 7
+8 XXXXXXXXXX 8
+9 XXXXXXXXXX 9
+ 0123456789
+Uh oh! You blew up!
+```
+
+**Inputs**
+
+To write test cases, you must type ">>>" followed by the name of the function that you wish to test on. Since you will mostly be testing the main function it would look like the following:
+
+```text
+>>> main()
+```
+
+**Outputs**
+
+Right after the declaring the function that you want to test, you would place that function's output right below it like so:
+
+```text
+>>> main()
+Hello World!
+```
+
+**Handling User Input**
+
+If your program needs user input, then you must include the following Python file:
+
+[https://gist.github.com/wongband/597c126217a306ca4770931680417faa](https://gist.github.com/wongband/597c126217a306ca4770931680417faa)
+
+The input.txt files should have the same numbering as the corresponding test files. For example, if you have input1.txt then that should correspond to minesweeper1.test.
+
+If, for instance, the minesweeper1.test file needs to have the input of 42, all we have to do is to create an input1.txt with 42 in it. **Do not put a new line if your program does not output a newline.**
+
+```text
+42
+```
+
+**Minesweeper Example**
+
+Below is the minesweeper1.test file. In this case we target the main function while passing the number 2 to it. Below that function, the output is the board and a prompt for the user input.
+
+```text
+Create Board Function
+>>> main(2)
+Mines: 10
+ 0123456789
+0 XXXXXXXXXX 0
+1 XXXXXXXXXX 1
+2 XXXXXXXXXX 2
+3 XXXXXXXXXX 3
+4 XXXXXXXXXX 4
+5 XXXXXXXXXX 5
+6 XXXXXXXXXX 6
+7 XXXXXXXXXX 7
+8 XXXXXXXXXX 8
+9 XXXXXXXXXX 9
+ 0123456789
+Enter your move (for help enter "H"): 42
+Mines: 10
+ 0123456789
+0 XXXXXXXXXX 0
+1 XXXXXXXXXX 1
+2 XXXXMXXXXX 2
+3 XXXXXXXXXX 3
+4 XXXXXXXXXX 4
+5 XXXXXXXXXX 5
+6 XXXXXXXXXX 6
+7 XXXXXXXXXX 7
+8 XXXXXXXXXX 8
+9 XXXXXXXXXX 9
+ 0123456789
+Uh oh! You blew up!
+```
+
+> Note: Each test case file should contain 5-10 unique test cases.
+
+#### Stage 4 - For Reviewers Only
+
+* [ ] **Bit Learning Management System \(LMS\)**
+
+ We have a LMS built to help us teach students step by step how to tackle complex and technical problems. In addition, we are open source so we are looking forward to finishing up LMS and creating small enough issues to let anyone contribute to our project.
+
+For the LMS to work, each module has a folder structure to follow.
+
+Walk through example:
+
+On the Bit curriculum Github, there is a module you should use as an example when trying to structure your module. Follow along by going to [https://bitproject.org/curriculum](https://bitproject.org/curriculum).
+
+Once at the link it should look like this. We’re going to go into the Data-Structures-and-Algos-Topic.
+
+
+
+You see how each module’s names are formatted Module\# name. Please do only use dashes \(-\) between words as any colons, semicolons, and slashes \(: ; / \) will mess with Github and cause trouble.
+
+Then into Module1-Intro-to-Data-Structures-and-Algos
+
+
+
+Again, you see how activite’s names are formatted with Activity\# name and it’s title in one chunk but capitalized every first letter of each word. Please do only use dashes \(-\) between words as any colons, semicolons, and slashes \(: ; / \) will mess with Github and cause trouble.
+
+Then into Activity1\_TimeAndSpaceComplexity
+
+
+
+It should look something like this:
+
+
+
+You can already see the way that this activity is being organized. Cards, checkpoints, and images goes in their own folder. Check out each of the folders and see how things are named.
+
+Cards are named from 1.md to \#.md.
+
+Checkpoints are named card\#-checkpoint.md.
+
+Images are named what the image is related to.
+
+Notice, the most important here is the README.md. The format of readmes have been documented here [https://about.bitproject.org/teams/engineering/readme-formats](https://about.bitproject.org/teams/engineering/readme-formats). Please follow the documentation and use the example in Github as a guide. Make sure you have all the information.
+
+\*NOTE: Gems will be explained in the next step so don’t worry about it yet.
+
+* [ ] **Gems**
+
+ Gems are something that students will receive upon completing a set of activities. Due to the difference in difficulty for each set of activities across all the modules, a set amount of gems does not make sense. To solve this issue, one of our members had created a Python script that you can run to calculate the number of gems that you should record in the readme of each activity.
+
+The idea is that if you per-assign a certain number of gems to each hard card and you know the amount of mediums and easy's under that given hard card, you can use the algorithm to calculate the entirety of the gem amounts for the rest of the cards.
+
+The script is written to assign points based on the types of cards. It’s in Python so make sure you have some sort of Python editor available for use. Download and open to follow along:
+Calculates the amount of exp to subtract from medium
+
+**and easy cards for a single hard card \(NOT the entire lab\)**
+
+def assignPoints\(basePts, numCards\):
+
+```text
+ # subtract the bonus
+ bonusRate = 0.1
+ bonus = bonusRate * basePts
+ basePtsNoBonus = basePts - bonus
+
+ # get amount to subtract for medium and easy cards
+ totalWeights = numCards["medium"] + numCards["easy"] * 2
+ subAmountM = basePtsNoBonus / totalWeights
+ subAmountE = subAmountM * 2
+
+ # floor amts
+ subAmountM //= 1
+ subAmountE //= 1
+ print("Hard card: " + str(basePts))
+ print("Medium card: " + str(subAmountM))
+ print("Easy card: " + str(subAmountE))
+
+ def main():
+ numMed = int(input("Enter number of medium cards under this hard card: "))
+ numEasy = int(input("Enter number of easy cards under this hard card: "))
+ basePts = int(input("Enter the exp split amount for this hard card: "))
+
+ numCards = {"medium" : numMed, "easy" : numEasy}
+ assignPoints(basePts, numCards)
+
+ n = 0
+ while (n >= 0):
+ main()
+ n -= 1
+```
+
+_Step 1:_ Open the file with a Python editor.
+
+_Step 2:_ If you only need it once, just run the program. If you want to calculate more than once, you can change the number that the variable N \(line 30\) is assigned as. It’s set up to loop N times.
+
+```text
+ 
+```
+
+_Step 3:_ Enter all the inputs requested and press enter.
+
+```text
+ 
+```
+
+_Step 4:_ With the results, please consult Kevin for the number of gems.
+
+* [ ] **Proofreading by the Writing Team**
+
+ This is the very last step of development. Please send your contents to the writing team \(currently Victoria Xu @@vkxu657 on Github\).
+
+This is important to make sure all the content is syntactically and grammatically correct so students won’t have trouble with the material for maximum understanding.
+
+It is your responsibility as a manager to raise any issues that are reported and issued to a member of your team to fix it by a deadline. All the writer’s changes should be integrated into your weekly PRs.
+
+## Developer
+
+For Developers, this checklist will be used to help guide them in the production of curriculum. It will serve as a checklist to help determine what a developer should or should not do when they are creating labs and activities.
+
+For Example, as developers are doing the activity cards, there is a checklist box that states that there must be 2-3 checkpoints in the activity. By using this checklist as a guide, developers would then remember to add checkpoints somewhere in the list. This would then save the developer's reviewer's time as the reviewer would not have to ask the developer to add the missing content and wait again for the developer to implement what is missing.
+
+## Manager
+
+For Managers, this guide will be useful for checking on the work of the developers. Managers can refer to this checklist page to see what the developers did wrong, making giving feedback easier than ever.
+
+For example, In the following we have Michelle as a Manager/Reviewer. In the pull request Checklist portion of this page, there is a checkbox that states "Correct Markdown Formatting", and as seen below, that checkbox was put to good use. By checking in this page, it is now easier to spot what needs to be revised, leading to faster and more efficient feedback given to the developer.
+
+
+
+## Kevin
+
+This is the second layer for reviewing the curriculum. Kevin is in charge of further looking into the content of the written curriculum. Specifically, he is in charge of the pull requests made by the managers. As a result, he needs to review a lot of curriculum, and using this checklist will further help save time and work in the reviewing process.
+
+In the following example, Kevin saw the 1 scroll per card checkbox, and therefore made the following review:
+
+
+
+## Daniel
+
+Our Leader Daniel is the final layer in the review process. He Double checks what Kevin reviews and makes sure that the curriculum being used is as close to perfection as possible. And it is through this checklist that his job can be made easier as he just needs to use it as a guide to see what the other reviewers may have missed out on.
+
diff --git a/teams/developer-relations/bible-for-developers/README.md b/teams/developer-relations/bible-for-developers/README.md
new file mode 100644
index 0000000..b6e8b2a
--- /dev/null
+++ b/teams/developer-relations/bible-for-developers/README.md
@@ -0,0 +1,109 @@
+# Bible for Developers
+
+## General Checklist
+
+#### General Items \(Apply to All Stages\)
+
+* [ ] High-schooler friendly writing style, easy to understand
+* [ ] Correct numbering
+* [ ] Every card has code\*
+* [ ] 1 scroll per card\*\*
+* [ ] Proper grammar, punctuation, capitalization, etc.
+* [ ] Acceptable Styling per the Pull Request Checklist
+
+\*Exception being hard and medium cards in labs as well as activity cards that just introduce concepts
+
+\*\* If you have to scroll more than once to view the whole card, the card is too long
+
+{% page-ref page="general-items-breakdown.md" %}
+
+#### Stage 1 - Starting Content
+
+* [ ] Content of cards is more accessible to beginners
+* [ ] Micro to Macro Principle
+* [ ] Titles for Concepts associated with each Card
+
+#### Stage 1 - Lab Addendum
+
+* [ ] Hard cards provide enough guidance for the student to finish task
+* [ ] Mediums bridge Hards and Easys
+* [ ] Easy cards provide solution, are line-separated
+* [ ] Solution and starter code in Airtable and GitHub
+ * [ ] Code is testable, not too general
+
+{% page-ref page="stage-1-breakdown.md" %}
+
+#### Stage 2 - Finishing Content
+
+* [ ] Logical card progression
+* [ ] Ample pictures/custom visuals \(copyright-free, Pexels is a great source\)
+ * [ ] Images placed _locally_ with <img> NOT Markdown
+ * [ ] all <img> tags should close properly <img ... />
+* [ ] \(For activities\) Fleshed-out, real-life scenarios
+* [ ] 2-3 Checkpoints \(Types: Short Answer, Image, Multiple Choice, Video, Autograder/Code\)
+* [ ] All concepts fleshed out
+
+#### Stage 2 - Lab Addendum
+
+* [ ] Medium and easy cards split into hints
+* [ ] 2-3 code checkpoints, depending on length of lab
+ * [ ] Solution Code for checkpoints
+
+{% page-ref page="stage-2-breakdown.md" %}
+
+#### Stage 3 - Finishing Touches
+
+* [ ] Correct formatting according to READMEs
+ * [ ] Modules
+ * [ ] Activities
+ * [ ] Labs
+ * [ ] Hints \(Medium + Easy Cards\)
+ * [ ] Concepts
+ * [ ] Checkpoints
+ * [ ] With test cases for checkpoints if applicable
+* [ ] Concepts for each card completely finalized, with correct README formatting
+
+**Stage 3 - Lab Addendum**
+
+* [ ] 5-10 test cases, correctly formatted according to READMEs
+
+{% page-ref page="stage-3-breakdown.md" %}
+
+#### Stage 4 - For Reviewers Only
+
+* [ ] Assigned modules' folders properly structured within topics
+* [ ] Gem Amounts
+ * Labs: calculated using John's Code
+ * Activities: Predetermined amounts
+* [ ] Have curriculum proofread by writing team \(currently Victoria Xu @vkxu657\)
+
+{% page-ref page="stage-4-breakdown.md" %}
+
+## How This Checklist Is Used Beyond Development
+
+### Developer
+
+For Developers, this checklist will be used to help guide them in the production of curriculum. It will serve as a checklist to help determine what a developer should or should not do when they are creating labs and activities.
+
+For example, as developers are doing the activity cards, there is a checklist box that states that there must be 2-3 checkpoints in the activity. By using this checklist as a guide, developers would then remember to add checkpoints somewhere in the list. This would then save the developer's reviewer's time as the reviewer would not have to ask the developer to add the missing content and wait again for the developer to implement what is missing.
+
+### Manager
+
+For Managers, this guide will be useful for checking on the work of the developers, streamlining the process of giving feedback.
+
+For example, in the following we have Michelle as a manager/reviewer. In the pull request checklist portion of this page, there is a checkbox that states "Correct Markdown Formatting", and as seen below, that checkbox was put to good use. By checking in this page, it is now easier to spot what needs to be revised, leading to faster and more efficient feedback given to the developer.
+
+
+
+### Kevin
+
+This is the second layer for reviewing the curriculum. Kevin is in charge of the pull requests made by the managers. As a result, he needs to review a lot of curriculum, and using this checklist will further help save time and work in the reviewing process.
+
+In the following example, Kevin saw the 1 scroll per card checkbox, and therefore made the following review:
+
+
+
+### Daniel
+
+Our Leader Daniel is the final layer in the review process. He double checks what Kevin reviews and makes sure that the curriculum being used is as close to perfection as possible. And it is through this checklist that his job can be made easier as he just needs to use it as a guide to see what the other reviewers may have missed out on.
+
diff --git a/teams/developer-relations/bible-for-developers/general-items-breakdown.md b/teams/developer-relations/bible-for-developers/general-items-breakdown.md
new file mode 100644
index 0000000..4e4f9c2
--- /dev/null
+++ b/teams/developer-relations/bible-for-developers/general-items-breakdown.md
@@ -0,0 +1,51 @@
+# General Items Breakdown
+
+### General Items \(Applies to All Stages\)
+
+* [ ] High-schooler friendly writing style, easy to understand
+* [ ] Correct numbering
+* [ ] Every card has code\*
+* [ ] 1 scroll per card\*\*
+* [ ] Proper grammar, punctuation, capitalization, etc.
+* [ ] Acceptable Styling per the Pull Request Checklist
+
+\*Exception being hard and medium cards in labs as well as activity cards that just introduce concepts
+
+\*\* If you have to scroll more than once to view the whole card, the card is too long
+
+Before going into a stage-by-stage breakdown, here's a general overview of things to keep in mind.
+
+#### Writing Style
+
+First and foremost, we want all our developers to use a conversational writing style when making cards. This is because the target audience for our curriculum is high school students, and our goal is to make technical education as accessible as possible. Writing as if you're having a conversation will keep students more engaged. When in doubt, think **blog post** instead of **calculus textbook**.
+
+#### Numbering
+
+It's crucial that each card is numbered correctly so developers can keep lessons organized and students can follow a logical progression. BitProject uses two numbering schemes, one for Activities and one for Labs.
+
+Here's an example of an Activity \(pretty self-explanatory\):
+
+
+
+And here's an example of a Lab:
+
+
+
+Each hard card is labelled as a single number.
+Going off of the above example, **1.md is the first hard card**, and **2.md is the second hard card**.
+
+To label medium cards, simply add another number associated with its order.
+In the above example, **1-1.md is the first medium card associated with the first hard card**, and
+**2-1.md is the first medium card associated with the second hard card**.
+
+To label easy cards, add another number associated with its order \(3 numbers total\).
+In the above example, **1-1-1.md is the first easy card associated with the first medium card associated with the first hard card.** Can you translate 2-1-1.md into plain English?
+
+#### Card Length
+
+Cards should be concise. Ideally, you should not have to scroll more than once to view the whole card. Stuffing a ton of information in a single card can be too overwhelming, so try to keep things brief and split up topics as much as possible.
+
+#### Writing Conventions
+
+Last but certainly not least, proper writing conventions such as grammar, punctuation, capitalization, etc. should be utilized.
+
diff --git a/teams/developer-relations/bible-for-developers/stage-1-breakdown.md b/teams/developer-relations/bible-for-developers/stage-1-breakdown.md
new file mode 100644
index 0000000..c3959fd
--- /dev/null
+++ b/teams/developer-relations/bible-for-developers/stage-1-breakdown.md
@@ -0,0 +1,46 @@
+# Stage 1 Breakdown
+
+### Stages
+
+Here's an in-depth breakdown of how cards progress in the BitProject system.
+
+#### Stage 1 - Starting Content
+
+**Card content should be accessible to beginners**, meaning someone with no prior knowledge should be able to follow the content. This goes hand-in-hand with using a conversational writing style.
+
+Next up is what we call the **Micro to Macro Principle**. For labs and activities, please start at a micro level and then move up. For example, students should not code the main\(\) function first. As a rule of thumb, you should never have to utter the words “this function will be coded in a later part”. Every hard card should work on its own and not have to rely on later work for it to work out.
+
+
+
+**Images**! Make liberal use of images \(like the one above\) in your cards. It's much easier to visualize a concept than to read three paragraphs of text. Obviously, text is necessary, but pairing text with visuals is immensely helpful. Also, images help break up blocks of text, making it easier on the eyes. Please use copyright-free images, Pexels is a great source. Make sure images are embedded using <img> tags and not URLs.
+
+Activities and Labs will feature coding tasks for students to complete. For these, developers should implement what we call **checkpoints**—Python console output that serves as a frame of reference for students to make sure their code is doing what it's supposed to be doing.
+
+**Titles**. These should be included in HTML comments at the top of each card, not in the file name itself \(remember, cards are named numerically\). Along with titles, **concepts** covered in the card should also be contained in HTML comments. Here's an example:
+
+
+
+**Card length** should be reasonable. Ideally, keep the entire card viewable with at most one scroll.
+Students will have a hard time staying focused if a card is too long, and shorter cards are easier to digest. Try to split up topics as much as possible.
+
+This one is pretty self-explanatory, but make sure your cards progress in a way that makes sense.
+
+#### Stage 1 - Lab Addendum
+
+
+
+When creating a Lab, you are essentially giving the student a problem to solve, breaking it down into steps, with each step subdivided into cards of hard, medium, and easy difficulty. An example might be to code a Python program that can solve Sudoku.
+
+When it comes to Labs, there are a number of things to keep in mind.
+
+**Hard cards** are, by definition, _hard._ A hard card for the Sudoku Solver Lab might explain the game of Sudoku and have a teeny-tiny bit of **starter code** at the end. Keep in mind that, although this card should stretch the student's brain, it should also provide just enough guidance for the student to finish the task. The main thing to keep in mind is you _should NOT_ leak any hints_._ Example [here](https://github.com/bitprj/curriculum/blob/master/Data-Structures-and-Algos-Topic/labs/Lab6_Sudoku_Solver/Cards/1.md).
+
+**Medium cards** are probably the most difficult cards to make, since you have to find a delicate middle ground between hard and easy. That said, keep in mind that the goal of medium is to serve as a bridge between hard and easy. You start to squeeze out a few hint droplets into the student's cup, but don't fill the entire cup. Example [here](https://github.com/bitprj/curriculum/blob/master/Data-Structures-and-Algos-Topic/labs/Lab6_Sudoku_Solver/Cards/11.md).
+
+**Easy cards** should literally walk the student through the problem step-by-step. Imagine leading a blindfolded person through a mine\(sweeper\) field. Functions should be completely written out, and explanations should be given for _everything._ Expanding on the juice analogy—fill the student's cup! Example [here](https://github.com/bitprj/curriculum/blob/master/Data-Structures-and-Algos-Topic/labs/Lab6_Sudoku_Solver/Cards/111.md).
+
+It's probably a good idea to first make your hard and easy cards for a topic, then do medium last.
+That way, you give yourself boundaries that your medium card shouldn't cross.
+
+A word about **code**. All Lab cards should contain code, with varying degrees depending on card difficulty. Make sure code is _testable_, meaning a student can copy-paste your code into an IDE and have it output something meaningtul to the problem at hand.
+
diff --git a/teams/developer-relations/bible-for-developers/stage-2-breakdown.md b/teams/developer-relations/bible-for-developers/stage-2-breakdown.md
new file mode 100644
index 0000000..cf91e7d
--- /dev/null
+++ b/teams/developer-relations/bible-for-developers/stage-2-breakdown.md
@@ -0,0 +1,24 @@
+# Stage 2 Breakdown
+
+#### Stage 2 - Finishing Content
+
+The bulk of your content has been finished. Here are a few more things to top off your cards.
+
+Each card should reward the student a certain number of **gems** upon completion. Think of these as currency in a video game. Students will be able to spend gems to unlock things like hints as they progress further through curriculum tracks. Gem numbers should be included in the README file for the Activity/Lab.
+
+
+
+For each Activity and Lab, **three criteria statements** must be provided. Each criteria should outline an important takeaway from the Activity/Lab. Teachers will be referencing this criteria when grading students’ videos of Activities and Labs, and students will have to meet all criteria to proceed. The criteria can be in statement or question format and should be included in the README file for the Activity/Lab. Here's an example:
+
+
+
+Each Activity/Lab should contain a brief **summary** describing it using 1 sentence only. In addition, please provide a **long summary** that expands on the main concepts covered in the Activity/Lab, about 3-4 sentences total. Here's an example:
+
+
+
+#### Stage 2 - Lab Addendum
+
+For each lab, **test cases** must be provided. Make sure your lab is concise enough so that test cases can be made. For example, if you were making a Wheel of Fortune lab, don’t ask users to make their own lists of possible messages. Instead, create the messages yourself and have them simply make a list out of those predefined messages. In the scenario where students get to create their own list, it would be impossible to actually define test cases for each student’s custom list.
+
+For the test cases, simply provide a document detailing what should be inputted and its output. There should be around 8-10 test cases per Lab.
+
diff --git a/teams/developer-relations/bible-for-developers/stage-3-breakdown.md b/teams/developer-relations/bible-for-developers/stage-3-breakdown.md
new file mode 100644
index 0000000..6f6ecf0
--- /dev/null
+++ b/teams/developer-relations/bible-for-developers/stage-3-breakdown.md
@@ -0,0 +1,934 @@
+# Stage 3 Breakdown
+
+
+
+### Stage 3 Documentation \(Atul\)
+
+> Note: All elements of a unit \(Module,Activity,Topic,etc.\) are REQUIRED unless stated otherwise.
+
+#### Topic README Format
+
+**Github ID**
+
+Each topic needs a `github_id` so that the server knows it is unique. The word `github_id` should be in a markdown `h1` tag like below:
+
+```text
+# github_id
+1
+```
+
+**Name**
+
+Each Topic needs a `name` field. The word `name` should be in markdown `h1` tag like below:
+
+```text
+# name
+Postman Topic
+```
+
+**Description**
+
+Each Topic has a `description` field to describe what the topic will help accomplish. The word `description` should be in markdown h1 tag like below:
+
+```text
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+```
+
+**Image**
+
+Each Topic has an `image` field. The word `image` should be in markdown `h1` tag while the image `url` must be in an `img` tag:
+
+```text
+# image
+
+```
+
+**Image Folder**
+
+Each Topic needs to point to an image folder where image\(s\) are being used. The word `image_folder` should be in a markdown `h1` tag like below:
+
+```text
+# image_folder
+/Topic_Postman/
+```
+
+**Modules**
+
+Each Topic has modules. To add modules to a topic, add the module's `github_ids` in a list. Add the word `modules` in a markdown `h1` tag and then add the `github_id`s in a list with \*'s:
+
+```text
+# modules
+* 5
+```
+
+**Topic README Example**
+
+```text
+# github_id
+1
+
+# name
+Postman Topic
+
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+
+# image
+
+
+# image_folder
+/Topic_Postman/
+
+# modules
+* 5
+```
+
+#### Module README Format
+
+**Github ID**
+
+Each module needs a `github_id` so that the server knows it is unique. The word `github_id` should be in a markdown `h1` tag like below:
+
+```text
+# github_id
+1
+```
+
+**Name**
+
+Each Module needs a `name` field. The word `name` should be in markdown `h1` tag like below:
+
+```text
+# name
+Some Module 2
+```
+
+**Description**
+
+Each Module needs a `description` field to describe what the module will help accomplish. The word `description` should be in markdown `h1` tag like below:
+
+```text
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+```
+
+**Gems Needed**
+
+Each Module needs a `gems_needed` field which is the number of gems needed to unlock the module. The word `gems_needed` should be in markdown `h1` tag like below:
+
+**Note: Set it as 0 for now**
+
+```text
+# gems_needed
+0
+```
+
+**Image**
+
+Each Module needs an image field that visually represents the theme of the module.. The word `image` should be in markdown `h1` tag while the image `url` should be put in an `img` tag:
+
+```text
+# image
+
+```
+
+**Image Folder**
+
+Each Module needs to point to an image folder where the image is being used. The word `image_folder` should be in a markdown `h1` tag like below:
+
+```text
+# image_folder
+Topic_1/Module2_test/
+```
+
+**Final Example**
+
+```text
+# github_id
+1
+
+# name
+Some Module 2
+
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+
+# gems_needed
+ 0
+
+# image
+
+
+# image_folder
+Topic_1/Module2_test/
+```
+
+#### Activity/Lab README Format
+
+**Github ID**
+
+Each Activity/Lab needs a `github_id` so that the server knows it is unique. The word `github_id` should be in a markdown `h1` tag like below:
+
+```text
+# github_id
+1
+```
+
+**Name**
+
+Each Activity/Lab needs a `name` field. The word `name` should be in markdown `h1` tag like below:
+
+```text
+# name
+Some Activity
+```
+
+**Description**
+
+Each Module needs a `description` field to describe what the module will help accomplish. The word `description` should be in markdown `h1` tag like below:
+
+```text
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip.
+```
+
+**Summary**
+
+Each Activity/Lab has a `summary` field to describe what the activity will help accomplish **in more detail**. The word `summary` should be in markdown `h1` tag like below:
+
+```text
+# summary
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+```
+
+**Difficulty**
+
+Each Activity/Lab needs a `difficulty` field to indicate how hard the Activity/Lab is for the user. Add the word `difficulty` in a markdown `h1` tag, and put the difficulty under it:
+
+There are 3 types of `difficulty`:
+
+* Hard
+* Medium
+* Easy
+
+```text
+# difficulty
+Hard
+```
+
+**Image**
+
+Each Activity/Lab needs an `image` field that visually represents the theme of the module.. The word `image` should be in markdown `h1` tag while the image `url` should be put in an `img` tag:
+
+```text
+# image
+
+```
+
+**Image Folder**
+
+Each Activity/Lab needs to point to an image folder where the image is being used. The word `image_folder` should be in a markdown `h1` tag like below:
+
+```text
+# image_folder
+Topic1/Module2_test/Activity_4/
+```
+
+**Cards**
+
+The `cards` fields is used to indicate: the name of the card, the order in which the card will be shown, as well as the number of gems that the card is worth.
+
+* **Cards**
+
+To define cards in an Activity, you have to have the word `cards` in a markdown `h1` tag. This is used to tell the server where the cards are:
+
+```text
+# cards
+```
+
+* **Card Key**
+
+Each card you define in the Activity README must have a corresponding filename as its key. For example if a card/hint was named 1.md then its key would be 1. The card key must be placed in a markdown `h2` tag like below:
+
+```text
+## 1
+```
+
+* **Card Name**
+
+Each card has a `name` field. Each name should be in a markdown `h3` tag like below:
+
+```text
+### name
+Card 1 Github
+```
+
+* **Card Order**
+
+Each card has an order field. The order is the last digit of the card key. If a card had a key of 1-2, then the order for that card would be 2. Each `order` should be in a markdown h3 tag like below:
+
+```text
+### order
+2
+```
+
+* **Card Gems**
+
+Each card has a `gems` field. The gems fields is used to indicate the number of gems earned when opening a card. If this for a medium/easy card, this field is for the amount of gems a student would **lose** for using the medium/easy card. Each name should be in a markdown `h3` tag like below:
+
+```text
+### gems
+300
+```
+
+* **Card Concepts \(Only applies to Hard Cards\)**
+
+To give a card concepts, write the word `concepts` in a markdown `h3` tag and list out the name of the concepts using an \* like below:
+
+```text
+### concepts
+* concept_1.md
+* concept_2.md
+```
+
+> Note: When defining the cards, please put them in order of difficulty. Hard cards should be defined first, Medium cards next, and last easy cards. Below is an example:
+
+```text
+# cards
+
+## 1
+
+### name
+Bleh Card 1 Github
+
+### order
+1
+
+### gems
+300
+
+### concepts
+* concept_1.md
+* concept_2.md
+
+## 2
+
+### name
+Bleh Card 2 Github
+
+### order
+2
+
+### gems
+300
+
+## 1-1
+
+### name
+Bleh Card 2 Github
+
+### order
+1
+
+### gems
+300
+
+## 2-1
+
+### name
+Bleh Card 4 Github
+
+### order
+1
+
+### gems
+300
+
+## 1-1-1
+
+### name
+Bleh Card 3 Github
+
+### order
+1
+
+### gems
+300
+
+## 1-2-1
+
+### name
+Bleh Card 4 Github
+
+### order
+1
+
+### gems
+300
+
+## 2-1-1
+
+### name
+Bleh Card 131 Github
+
+### order
+1
+
+### gems
+300
+```
+
+**Final Example**
+
+```text
+# github_id
+19
+
+# name
+Some Activity
+
+# description
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip.
+
+# summary
+Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum
+
+# difficulty
+Hard
+
+# image
+
+
+# image_folder
+Topic1/Module2_test/Activity_4/
+
+# cards
+
+## 1
+
+### name
+Card 1 Github
+
+### order
+2
+
+### gems
+300
+
+## 1-1
+
+### name
+Medium Card
+
+### order
+1
+
+### gems
+100
+```
+
+#### Hint README Format \(Medium/Easy Cards\)
+
+**Image Folder**
+
+Each Hint needs to point to an image folder.
+
+```text
+# image_folder
+Topic1/Module2_test/Activity_7/cards
+```
+
+**Start of the Steps**
+
+You must include the word `steps` in a markdown `h1` tag so the server knows when the actual steps of the hints start like below:
+
+```text
+# steps
+```
+
+**Step Key**
+
+Next you **must** include the step key so the server can keep track of the individual steps. The Step key should be the hint/card name along with the step number in a markdown `h1` tag like this:
+
+```text
+## 1-2-1 Step 1
+```
+
+**Step Name**
+
+Under the hint name, you have to give the step a name with a markdown `h2` tag. **Please put the contents of name in a code block.** It should look something like this:
+
+```text
+### name
+How to install VSCode
+```
+
+**MD Content \(You need to include this for each step\)**
+
+To include the actual content for the step, include the `md_content` with a markdown `h2` tag. **Please put the contents of md\_content in a code block.** It should look something like this:
+
+```text
+### md_content
+Hello world in js. This is how you do it
+```
+
+**Optional Fields**
+
+* **Code Snippet**
+
+To include a code snippet for the step, include the `code_snippet` with a markdown `h2` tag. **Please put the contents of the code in a code block.** It should look something like this:
+
+```text
+### code_snippet
+def pls_work(): return True... maybe
+```
+
+* **Image**
+
+To include an image for a step, you need to put a `h2` markdown tag and assign it to `image`
+
+```text
+### image
+
+```
+
+**Final Example:**
+
+Note: You can always add more steps as long as you follow the above syntax.
+
+```text
+# image_folder
+Topic1/Module2_test/Activity_7/cards
+
+# steps
+
+## 1-2-1 Step 1
+
+### name
+How to install VSCode
+
+### md_content
+Hello world in js. This is how you do it
+
+### code_snippet
+def pls_work(): return True... maybe
+
+### image
+
+```
+
+#### Concept README Format
+
+**Concept Name**
+
+Each concept needs a `name`.
+
+```text
+# concept_name
+Concept name
+```
+
+**Image Folder**
+
+Each Concept needs to point to an image folder.
+
+```text
+# image_folder
+Topic1/Module2_test/concepts/
+```
+
+**Step Key**
+
+Next you **must** include the step key.
+
+```text
+# concept_name Step 1
+```
+
+**Step Name**
+
+Under the hint name, you have to give the step a name with a markdown `h2` tag.
+
+```text
+## name
+How to install VSCode
+```
+
+**MD Content**
+
+Include `md_content` as below:
+
+```text
+## md_content
+Hello world in js. This is how you do it.
+```
+
+**Optional Fields**
+
+* **Code Snippet**
+
+Include `code_snippet` like below:
+
+```text
+## code_snippet
+def pls_work(): return True... maybe
+```
+
+* **Image**
+
+Include an `image` like below:
+
+```text
+## image
+
+```
+
+* **Final Example:**
+
+Note: You can always add more steps as long as you follow the above syntax.
+
+```text
+# concept_name
+Concept name
+
+# image_folder
+Topic1/Module2_test/concepts/
+
+# 1-2-1 Step 1
+
+## name
+How to install VSCode
+
+## md_content
+Hello world in js. This is how you do it
+
+## code_snippet
+def pls_work(): return True... maybe
+
+## image
+
+```
+
+#### Checkpoint README Format
+
+**Filename**
+
+For the file name, name it the card that you want it to be associated with. So if you wanted to create a checkpoint for 1.md, you would name the checkpoint file `1-checkpoint.md`
+
+**Name**
+
+Every checkpoint needs a `name`:
+
+```text
+# name
+Code Check in
+```
+
+**Cards Folder**
+
+Every checkpoint needs a `cards_folder`:
+
+```text
+# cards_folder
+Topic1/Module7/Activity_13/cards/
+```
+
+**Checkpoint Type**
+
+This is to define the type of checkpoint. Put `checkpoint_type` in a markdown `h1` tag.
+
+Checkpoints could be **ONE** of the following:
+
+* Video
+* Image
+* Short Answer
+* Multiple Choice
+* Autograder
+
+```text
+# checkpoint_type
+Video
+```
+
+**Instruction**
+
+This is what you would tell the user to do for a checkpoint. Put the word `instruction` in a markdown `h1` tag. Put the instruction content under the `h1` tag like so:
+
+```text
+# instruction
+Submit a photo your Minsweeper code working
+```
+
+**Other Fields**
+
+* **Criteria \(Required for Video and Image Checkpoints Only\)**
+
+Criteria correspond to a rubric for TAs to grade a student's Image or Video Checkpoint.
+
+You must declare where the criteria for a checkpoint would begin. You would do this by putting the word `criteria` in a markdown `h1` tag like so:
+
+```text
+# criteria
+```
+
+After that you can list each criteria in a markdown `h2` tag with a number at the end like so:
+
+```text
+## criteria_1
+Does the student's board look like this:
+```
+
+* **Multiple Choice \(Only for MC Checkpoints\)**
+
+You must declare where the choices for the checkpoint would begin. You would do this by putting the words `mc_choices` in a markdown `h1` tag like so:
+
+```text
+# mc_choices
+```
+
+Next you would define each choice in a markdown `h2` tag with a number at the end like so:
+
+```text
+## choice_1
+```
+
+* **Files to send \(Autograder Checkpoint Only\)**
+
+These are the files that the student will submit if the student chooses to submit through their code to the `cli`.
+
+```text
+# files_to_send
+main.py class1.py class2.py
+```
+
+**Test file location \(Autograder Checkpoint Only\)**
+
+This field is used to tell where the test case folder is for the checkpoint.
+
+```text
+# test_file_location
+Topic1/Module7/Activity_13/Tests/test_1
+```
+
+#### Checkpoint Examples
+
+**Video/Image**
+
+```text
+# name
+Code Check in
+
+# cards_folder
+Topic1/Module7/Activity_13/Cards/
+
+# checkpoint_type
+Video
+
+# instruction
+Submit a photo your Minsweeper code working
+
+# criteria
+
+## criteria_1
+Does the student's board look like this?
+
+## criteria_2
+Does the student's code print the board out?
+```
+
+**Short Answer**
+
+```text
+# name
+Print Statements Short Answer
+
+# cards_folder
+Topic1/Module7/Activity_13/Cards/
+
+# checkpoint_type
+Short Answer
+
+# instruction
+Submit a photo your Minsweeper code working
+```
+
+**Multiple Choice**
+
+```text
+# name
+Print Statement Multiple Choice
+
+# cards_folder
+Topic1/Module7/Activity_13/Cards/
+
+# checkpoint_type
+Multiple Choice
+
+# instruction
+Which of the following choices is the correct way to use a print statement in python
+
+# mc_choices
+
+## choice_1
+console.log()
+
+## choice_2
+print()
+
+## choice_3
+printf()
+
+# correct_choice
+print()
+```
+
+**Autograder**
+
+```text
+# name
+Autograder Checkpoint
+
+# cards_folder
+Topic1/Module7/Activity_13/Cards/
+
+# checkpoint_type
+Autograder
+
+# instruction
+Do this
+
+# files_to_send
+main.py class1.py class2.py
+
+# test_file_location
+Topic1/Module7/Activity_13/Tests/test_1
+```
+
+#### Test Cases README Format
+
+> Note: All test case files must end with .test
+
+**File formatting**
+
+If you have multiple test cases they should have a number at the end of their filenames like below:
+
+**Your test case must be named after the lab/activity and then contain a number in sequential order:**
+
+* minesweeper1.test
+* minesweeper2.test
+* minesweeper3.test
+
+If you have input files, then make sure that their name has a .txt extension. **They should be in numerical order as like this**:
+
+* input1.txt
+* input2.txt
+* input3.txt
+
+**Name**
+
+Each test case file must have a `name`:
+
+```text
+Board Function
+>>> main(2)
+Mines: 10
+ 0123456789
+0 XXXXXXXXXX 0
+1 XXXXXXXXXX 1
+2 XXXXXXXXXX 2
+3 XXXXXXXXXX 3
+4 XXXXXXXXXX 4
+5 XXXXXXXXXX 5
+6 XXXXXXXXXX 6
+7 XXXXXXXXXX 7
+8 XXXXXXXXXX 8
+9 XXXXXXXXXX 9
+ 0123456789
+Enter your move (for help enter "H"): 42
+Mines: 10
+ 0123456789
+0 XXXXXXXXXX 0
+1 XXXXXXXXXX 1
+2 XXXXMXXXXX 2
+3 XXXXXXXXXX 3
+4 XXXXXXXXXX 4
+5 XXXXXXXXXX 5
+6 XXXXXXXXXX 6
+7 XXXXXXXXXX 7
+8 XXXXXXXXXX 8
+9 XXXXXXXXXX 9
+ 0123456789
+Uh oh! You blew up!
+```
+
+**Inputs**
+
+To write test cases, you must type ">>>" followed by the name of the function that you wish to test on. Since you will mostly be testing the main function it would look like the following:
+
+```text
+>>> main()
+```
+
+**Outputs**
+
+Right after the declaring the function that you want to test, you would place that function's output right below it like so:
+
+```text
+>>> main()
+Hello World!
+```
+
+**Handling User Input**
+
+If your program needs user input, then you must include the following Python file:
+
+[https://gist.github.com/wongband/597c126217a306ca4770931680417faa](https://gist.github.com/wongband/597c126217a306ca4770931680417faa)
+
+The input.txt files should have the same numbering as the corresponding test files. For example, if you have input1.txt then that should correspond to minesweeper1.test.
+
+If, for instance, the minesweeper1.test file needs to have the input of 42, all we have to do is to create an input1.txt with 42 in it. **Do not put a new line if your program does not output a newline.**
+
+```text
+42
+```
+
+**Minesweeper Example**
+
+Below is the minesweeper1.test file. In this case we target the main function while passing the number 2 to it. Below that function, the output is the board and a prompt for the user input.
+
+```text
+Create Board Function
+>>> main(2)
+Mines: 10
+ 0123456789
+0 XXXXXXXXXX 0
+1 XXXXXXXXXX 1
+2 XXXXXXXXXX 2
+3 XXXXXXXXXX 3
+4 XXXXXXXXXX 4
+5 XXXXXXXXXX 5
+6 XXXXXXXXXX 6
+7 XXXXXXXXXX 7
+8 XXXXXXXXXX 8
+9 XXXXXXXXXX 9
+ 0123456789
+Enter your move (for help enter "H"): 42
+Mines: 10
+ 0123456789
+0 XXXXXXXXXX 0
+1 XXXXXXXXXX 1
+2 XXXXMXXXXX 2
+3 XXXXXXXXXX 3
+4 XXXXXXXXXX 4
+5 XXXXXXXXXX 5
+6 XXXXXXXXXX 6
+7 XXXXXXXXXX 7
+8 XXXXXXXXXX 8
+9 XXXXXXXXXX 9
+ 0123456789
+Uh oh! You blew up!
+```
+
+> Note: Each test case file should contain 5-10 unique test cases.
+
diff --git a/teams/developer-relations/bible-for-developers/stage-4-breakdown.md b/teams/developer-relations/bible-for-developers/stage-4-breakdown.md
new file mode 100644
index 0000000..a0d5373
--- /dev/null
+++ b/teams/developer-relations/bible-for-developers/stage-4-breakdown.md
@@ -0,0 +1,115 @@
+# Stage 4 Breakdown
+
+#### Stage 4 - For Reviewers Only
+
+* [ ] **Bit Learning Management System \(LMS\)**
+
+ We have a LMS built to help us teach students step by step how to tackle complex and technical problems. In addition, we are open source so we are looking forward to finishing up LMS and creating small enough issues to let anyone contribute to our project.
+
+For the LMS to work, each module has a folder structure to follow.
+
+Walk through example:
+
+On the Bit curriculum Github, there is a module you should use as an example when trying to structure your module. Follow along by going to [https://bitproject.org/curriculum](https://bitproject.org/curriculum).
+
+Once at the link it should look like this. We’re going to go into the Data-Structures-and-Algos-Topic.
+
+
+
+You see how each module’s names are formatted Module\# name. Please do only use dashes \(-\) between words as any colons, semicolons, and slashes \(: ; / \) will mess with Github and cause trouble.
+
+Then into Module1-Intro-to-Data-Structures-and-Algos
+
+
+
+Again, you see how activite’s names are formatted with Activity\# name and it’s title in one chunk but capitalized every first letter of each word. Please do only use dashes \(-\) between words as any colons, semicolons, and slashes \(: ; / \) will mess with Github and cause trouble.
+
+Then into Activity1\_TimeAndSpaceComplexity
+
+
+
+It should look something like this:
+
+
+
+You can already see the way that this activity is being organized. Cards, checkpoints, and images goes in their own folder. Check out each of the folders and see how things are named.
+
+Cards are named from 1.md to \#.md.
+
+Checkpoints are named card\#-checkpoint.md.
+
+Images are named what the image is related to.
+
+Notice, the most important here is the README.md. The format of readmes have been documented here [https://about.bitproject.org/teams/engineering/readme-formats](https://about.bitproject.org/teams/engineering/readme-formats). Please follow the documentation and use the example in Github as a guide. Make sure you have all the information.
+
+\*NOTE: Gems will be explained in the next step so don’t worry about it yet.
+
+* [ ] **Gems**
+
+ Gems are something that students will receive upon completing a set of activities. Due to the difference in difficulty for each set of activities across all the modules, a set amount of gems does not make sense. To solve this issue, one of our members had created a Python script that you can run to calculate the number of gems that you should record in the readme of each activity.
+
+The idea is that if you per-assign a certain number of gems to each hard card and you know the amount of mediums and easy's under that given hard card, you can use the algorithm to calculate the entirety of the gem amounts for the rest of the cards.
+
+The script is written to assign points based on the types of cards. It’s in Python so make sure you have some sort of Python editor available for use. Download and open to follow along:
+Calculates the amount of exp to subtract from medium
+
+**and easy cards for a single hard card \(NOT the entire lab\)**
+
+def assignPoints\(basePts, numCards\):
+
+```text
+ # subtract the bonus
+ bonusRate = 0.1
+ bonus = bonusRate * basePts
+ basePtsNoBonus = basePts - bonus
+
+ # get amount to subtract for medium and easy cards
+ totalWeights = numCards["medium"] + numCards["easy"] * 2
+ subAmountM = basePtsNoBonus / totalWeights
+ subAmountE = subAmountM * 2
+
+ # floor amts
+ subAmountM //= 1
+ subAmountE //= 1
+ print("Hard card: " + str(basePts))
+ print("Medium card: " + str(subAmountM))
+ print("Easy card: " + str(subAmountE))
+
+ def main():
+ numMed = int(input("Enter number of medium cards under this hard card: "))
+ numEasy = int(input("Enter number of easy cards under this hard card: "))
+ basePts = int(input("Enter the exp split amount for this hard card: "))
+
+ numCards = {"medium" : numMed, "easy" : numEasy}
+ assignPoints(basePts, numCards)
+
+ n = 0
+ while (n >= 0):
+ main()
+ n -= 1
+```
+
+_Step 1:_ Open the file with a Python editor.
+
+_Step 2:_ If you only need it once, just run the program. If you want to calculate more than once, you can change the number that the variable N \(line 30\) is assigned as. It’s set up to loop N times.
+
+```text
+ 
+```
+
+_Step 3:_ Enter all the inputs requested and press enter.
+
+```text
+ 
+```
+
+_Step 4:_ With the results, please consult Kevin for the number of gems.
+
+* [ ] **Proofreading by the Writing Team**
+
+ This is the very last step of development. Please send your contents to the writing team \(currently Victoria Xu @@vkxu657 on Github\).
+
+This is important to make sure all the content is syntactically and grammatically correct so students won’t have trouble with the material for maximum understanding.
+
+It is your responsibility as a manager to raise any issues that are reported and issued to a member of your team to fix it by a deadline. All the writer’s changes should be integrated into your weekly PRs.
+
diff --git a/teams/developer-relations/guide-to-being-a-manager/README.md b/teams/developer-relations/guide-to-being-a-manager/README.md
index 38a0ee0..d1c9b61 100644
--- a/teams/developer-relations/guide-to-being-a-manager/README.md
+++ b/teams/developer-relations/guide-to-being-a-manager/README.md
@@ -32,15 +32,15 @@ This checklist will be posted within the issue and should all be completed withi
### Pre-approval: What To Do
* [ ] For each module,create a document that outlines the planned curriculum\(make sure to format it properly and according to the example\)
- * [ ] Make sure learning objectives are written and formatted properly
+ * [ ] Make sure learning objectives are written and formatted properly
* [ ] Make sure activity titles and descriptions written and formatted properly
* [ ] Make sure lab titles and descriptions written and formatted properly
### Role of Epics + Assigning Epic Points
-Epics represent long-term \(in the form of GitHub issues\) that will keep you on track to finish weekly assignment,activities & labs, and entire modules. These epics should be assigned points not based on how long they will take to complete but the overall, implementation based difficulty. Activity,Lab ,and workshop epics are assigned different points and they add up to represent the total weight/points of an entire module.
+Epics represent long-term \(in the form of GitHub issues\) that will keep you on track to finish weekly assignment,activities & labs, and entire modules. These epics should be assigned points not based on how long they will take to complete but the overall, implementation based difficulty. Activity,Lab ,and workshop epics are assigned different points and they add up to represent the total weight/points of an entire module.
-### Explanation of Role of Issues \(curriculum issues\)
+### Explanation of Role of Issues \(curriculum issues\)
Issues are assigned weekly to developers and represent a week's work that will help you reach your epics. These issues should help you push yourself further down your Epics. They should be succinct enough\(and must also follow the given format on GitHub\) for developers to understand but not get overwhelmed by too many details or work.
@@ -52,7 +52,7 @@ Milestones represent a person's and a team's weekly goals. They are comprised of
Issues\(GitHub\) should be added to Epics. On a higher level, they represent what things need to be down in order to take down an Epic and will help you breakdown your goals into more tangible ideas and tasks. Module,activities, and lab Epics will be given smaller issues that break them into more ,as previously stated, bit-sized chunks that you can further break down into weekly issues and Milestones.
-### Long-term Plan
+### Long-term Plan
A long-term plan should be clear for not only yourself but outsiders who might view it as well. It should follow a set format\(as shown below\) and should outline both major points that need to worked on and the time frame on when these issues will be dealt with. It should be realistic and extra care should be taken into considering that deadlines that you set might need to be adjusted\(so give yourself some "wiggle room"\)
@@ -75,10 +75,6 @@ A long-term plan should be clear for not only yourself but outsiders who might v
You should use ZenHub as a visual deadline guide and reminder. You will create Epics that will represent blocks on ZenHub. You will then adjust their size according to their perceived start date and deadline. You will also create sub-epics\(i.e activity,workshop labs, etc.\) that will also have their own deadlines\(that will build up the main module epic\).
-
-
-
-
## Weekly Manager Checklist
* [ ] Review developers' work and provide a review according to the Pull Request Checklist
@@ -140,9 +136,35 @@ With regards to this checklist, reviewers should do the following:
* Ensure that stage labels are being properly marked
* When entire checklist is checked off for an Epic, then that Epic should be completed and linked within a pull request to `master` to indicate completion
-### General Checklist
+### General Checklist \(Applies to All Stages\)
+
+Before going into a stage-by-stage breakdown, here's a general overview of things to keep in mind.
+
+#### Writing Style
+
+First and foremost, we want all of our curriculum developers to use a _**conversational writing style**_ when making cards. Strive to make card content accessible and engaging—students should not have to sit through boring lectures to obtain a technical education! Writing as if you're having a conversation will keep students more engaged. When in doubt, think _**blog post**_ instead of _**dry CS lecture!**_
+
+#### Numbering
+
+It's crucial that each card is numbered correctly so developers can keep lessons organized and students can follow a logical progression. Bit Project uses two numbering schemes, one for Activities and one for Labs.
+
+Here's an example of how to number _**Activity**_ cards \(pretty self-explanatory\):
+
+
-#### General Items \(Apply to All Stages\)
+And here's an example of how to number _**Lab**_ cards \(a bit more complicated, so we'll explain it after the image\):
+
+
+
+Each hard card is labelled as a _**single number**_.
+Going off of the above example, _**"1.md " is the first hard card**_, and _**"2.md" is the second hard card**_.
+
+To label medium cards, simply add another number associated with its order \(2 numbers total\).
+In the above example, _**"11.md" is the first medium card associated with the first hard card**_, and
+_**"21.md" is the first medium card associated with the second hard card**_.
+
+To label easy cards, add another number associated with its order \(3 numbers total\).
+In the above example, _**"111.md" is the first easy card associated with the first medium card associated with the first hard card.**_ _\*\*_
* [ ] High-schooler friendly writing style, easy to understand
* [ ] Correct numbering
@@ -151,38 +173,78 @@ With regards to this checklist, reviewers should do the following:
* [ ] Proper grammar, punctuation, capitalization, etc.
* [ ] Acceptable Styling per the Pull Request Checklist
-\*Exception being hard and medium cards in labs as well as activity cards that just introduce concepts
+Cards should be concise. Stuffing a ton of information in a single card can be too overwhelming, so try to keep things brief and split up topics as much as possible. Ideally, you should not have to scroll more than once to view the whole card.
+
+#### Writing Conventions
+
+Proper writing conventions such as grammar, punctuation, capitalization, etc. should be utilized.
+
+**Code**
+
+Since we teach programming-related topics, your cards are going to contain code. That said, only include code if it _**serves a purpose.**_
+
+Here are some more specific guidelines to follow:
+
+* Activities introduce concepts; thus, showing code is not a primary purpose
+* Labs push students to apply the concepts they've learned to a problem and will thus be more code-heavy \(more on this in the "Stage 1—Lab Addendum" section below\)
-\*\* If you have to scroll more than once to view the whole card, the card is too long
+### Stages
+
+Here's an in-depth breakdown of how managers should check card progress in the Bit Project system. We've split up the process into 4 stages. Read on to familiarize yourself!
#### Stage 1 - Starting Content
-* [ ] Content of cards is more accessible to beginners
-* [ ] Micro to Macro Principle
-* [ ] Titles for Concepts associated with each Card
+We really can't stress enough how much we love educational content that _**speaks to students.**_ Please use a conversational writing style!
+
+When walking students through code, progress as though you are writing a piece of software yourself. Start with the simplest pieces, like variables and functions that _**don't depend on any other code.**_ Progressively work your way up until `main()`. We call this the _**Micro to Macro Principle.**_
+
+
+
+_**Card length**_ should be reasonable. Ideally, keep the entire card viewable with at most one scroll. Students will have a hard time staying focused if a card is too long, and shorter cards are easier to digest.
+
+**.**
+
+**.**
+
+**.**
#### Stage 1 - Lab Addendum
-* [ ] Hard cards provide enough guidance for the student to finish task
-* [ ] Mediums bridge Hards and Easys
-* [ ] Easy cards provide solution, are line-separated
-* [ ] Solution and starter code in Airtable and GitHub
- * [ ] Code is testable, not too general
+
+
+When creating a Lab, you are essentially giving the student a problem to solve, breaking it down into steps, with each step subdivided into cards of hard, medium, and easy difficulty. An example of a Lab might be to code a Python program that can solve Sudoku.
+
+When it comes to Labs, there are a number of things to keep in mind.
+
+**Hard cards** should present a _**high-level overview**_ of the problem_._ Keep in mind that, although this card should stretch the student's brain, it should also provide all the relevant information for the student to finish the task. A hard card for the Sudoku Solver Lab might explain the game of Sudoku and have a bit of starter code _\*\*_to point students in the right direction. Example [here](https://github.com/bitprj/curriculum/blob/master/Data-Structures-and-Algos-Topic/labs/Lab6_Sudoku_Solver/Cards/1.md).
+
+**Medium cards** should start to shed some more light on the problem. For instance, you can let students know what kinds of variables to keep track of, what data structures to use, or how to set up a certain function. Provide some hints, but don't give it all away. Example [here](https://github.com/bitprj/curriculum/blob/master/Data-Structures-and-Algos-Topic/labs/Lab6_Sudoku_Solver/Cards/11.md).
+
+**Easy cards** should _literally_ walk the student through a section of the problem step-by-step. Functions should be completely written out, and code should be explained line-by-line_._ Example [here](https://github.com/bitprj/curriculum/blob/master/Data-Structures-and-Algos-Topic/labs/Lab6_Sudoku_Solver/Cards/111.md).
+
+A word about **code**. All Lab cards should contain code, with varying degrees depending on card difficulty \(hard = not much code, medium = some more code, easy = ALOT of code\). Make sure code is _testable_ and works on multiple operating systems—students should be able to copy-paste your code into an IDE and tinker with it on their own. Here's an illustrative example from an easy hard:
+
+
#### Stage 2 - Finishing Content
-* [ ] Logical card progression
-* [ ] Ample pictures/custom visuals \(copyright-free, Pexels is a great source\)
- * [ ] Images placed _locally_ with <img> NOT Markdown
-* [ ] \(For activities\) Fleshed-out, real-life scenarios
-* [ ] 2-3 Checkpoints \(Types: Short Answer, Image, Multiple Choice, Video, Autograder/Code\)
-* [ ] All concepts fleshed out
+Your cards should be almost finished by this stage. This section contains a few more crucial characteristics to top off your content.
+
+_**Images!**_ Make liberal use of them in your cards. Concepts don't fully click until students can visualize them. Please use copyright-free images, Pexels is a great source. Since we use markdown to construct our cards, make sure images are embedded using _**local <img> tags**_ \(don't use URLs\).
+
+_**Cards need to follow a logical progression**_. For Activities, this means that you start by introducing a concept in the first card, then move on to specifics of that concept in subsequent cards. For Labs, this means you walk the student through the problem step-by-step.
#### Stage 2 - Lab Addendum
-* [ ] Medium and easy cards split into hints
-* [ ] 2-3 code checkpoints, depending on length of lab
- * [ ] Solution Code for checkpoints
+_**Checkpoints**_ are crucial for checking students' progress in Activities and Labs. Checkpoints come in different types:
+
+* Multiple choice prompts
+* Short answer prompts
+* Images
+* Videos
+* Autocheck Graders
+
+There should be about 2-3 of these per Lab.
#### Stage 3 - Finishing Touches
@@ -208,5 +270,3 @@ With regards to this checklist, reviewers should do the following:
* Activities: Predetermined amounts
* [ ] Have curriculum proofread by writing team \(currently Victoria Xu @vkxu657\)
-
-
diff --git a/teams/developer-relations/joining-the-core-team.md b/teams/developer-relations/joining-the-core-team.md
index 0ae31af..fe26c3e 100644
--- a/teams/developer-relations/joining-the-core-team.md
+++ b/teams/developer-relations/joining-the-core-team.md
@@ -6,17 +6,17 @@ description: The process of joining the core team.
## Introduction
-In our efforts to go remote, we have established a very streamlined recruitment process for students to join our cause. Students from all over will be able to join as the onboarding process no longer requires an in-person meeting. It will utilize the following applications heavily: Zoom and GitHub.
+In our efforts to go remote, we have established a very streamlined recruitment process for students to join our cause. Students from all over will be able to join as the onboarding process no longer requires an in-person meeting. It will utilize the following applications heavily: Zoom and GitHub.
-This process involves multiple people: the applicant\(s\), managers, mentors, and more. It is expected to last about two weeks to ensure that you are smoothly integrated into one of the developer relations teams. The following list below is our breakdown of the onboarding process, assigning various tasks to certain individuals on specified dates.
+This process involves multiple people: the applicant\(s\), managers, mentors, and more. It is expected to last about two weeks to ensure that you are smoothly integrated into one of the developer relations teams. The following list below is our breakdown of the onboarding process, assigning various tasks to certain individuals on specified dates.
## Contributor Onboarding Checklist
-Contributor Name:
+Contributor Name:
-Manager Name:
+Manager Name:
-Mentor Name:
+Mentor Name:
### Pre-Interview Tasks:
@@ -130,31 +130,31 @@ Cover topics within next two weeks to ensure that the contributor is onboarded p
## Checklist Breakdown
-### Pre-Interview Tasks:
+### Pre-Interview Tasks:
-These are tasks for the manager in charge of onboarding. They are required to contact the applicant\(s\) through email once the applications are received. A zoom link is sent to them with a time and date for the Welcome Webinar. The manager is also in charge of notifying the president of Bit Project, and the applicants' prospective manager and mentor.
+These are tasks for the manager in charge of onboarding. They are required to contact the applicant\(s\) through email once the applications are received. A zoom link is sent to them with a time and date for the Welcome Webinar. The manager is also in charge of notifying the president of Bit Project, and the applicants' prospective manager and mentor.
### Manager Tasks:
-The manager is essentially the team leader of the applicant's potential team. They are in charge of making sure that you are caught up to speed with their current work and have a strong foundational understanding of the general curriculum.
+The manager is essentially the team leader of the applicant's potential team. They are in charge of making sure that you are caught up to speed with their current work and have a strong foundational understanding of the general curriculum.
#### Day 1:
-The manager would first confirm that all applicants are on Slack as Slack is our main form of communication. Having everyone on one platform that has multiple communication accessories make the remote process much simpler for everyone.
+The manager would first confirm that all applicants are on Slack as Slack is our main form of communication. Having everyone on one platform that has multiple communication accessories make the remote process much simpler for everyone.
-An introduction is necessary so applicants are aware of who is the person they should turn to. The manager would send a greeting to the applicants, providing the following information: name, team name, position, ways to contact the manager, and the mentor. The mentor is a member of the team that is familiar with working with the manager and is comfortable with the work given. Applicants can contact the mentor whenever they are struggling and are in need of help. Mentors are essentially another source of reference that is available.
+An introduction is necessary so applicants are aware of who is the person they should turn to. The manager would send a greeting to the applicants, providing the following information: name, team name, position, ways to contact the manager, and the mentor. The mentor is a member of the team that is familiar with working with the manager and is comfortable with the work given. Applicants can contact the mentor whenever they are struggling and are in need of help. Mentors are essentially another source of reference that is available.
-An info session will be scheduled. For now, this will be administered by another member of Bit Project until managers get settled with the new onboarding process. A more detailed explanation of the info session is provided in the Contributor Task Breakdown.
+An info session will be scheduled. For now, this will be administered by another member of Bit Project until managers get settled with the new onboarding process. A more detailed explanation of the info session is provided in the Contributor Task Breakdown.
-Managers will assign the member a first-timer task after the info session. These tasks vary based off of each individual team's current project. It is catered towards the project's focus.
+Managers will assign the member a first-timer task after the info session. These tasks vary based off of each individual team's current project. It is catered towards the project's focus.
#### Day 2-5:
-Throughout these few days, the manager and mentor will be helping contributors with their first-timer task whenever needed. They would review the task once it is officially submitted and take note of any major or minor mistakes. If there are major issues, these will be communicated through Slack soon after the task is submitted. It is best to review these as soon as possible to avoid the same mistakes from reoccurring in the future.
+Throughout these few days, the manager and mentor will be helping contributors with their first-timer task whenever needed. They would review the task once it is officially submitted and take note of any major or minor mistakes. If there are major issues, these will be communicated through Slack soon after the task is submitted. It is best to review these as soon as possible to avoid the same mistakes from reoccurring in the future.
#### Day 6:
-The manager should confirm the 1:1 meeting with each applicant. This should happen before Day 14 \(the end of the onboarding process\).
+The manager should confirm the 1:1 meeting with each applicant. This should happen before Day 14 \(the end of the onboarding process\).
#### Day 7-14:
@@ -164,50 +164,50 @@ During the scheduled one-on-one above, it will consist of a team introduction an
#### Day 0 \(Thursday\):
-Applicants are contacted via email and are invited to attend the welcome webinar. A zoom link will already be provided within the email with a set date and time. It is important to notify us whether or not you are able to attend by responding to the email with a confirmation of attendance.
+Applicants are contacted via email and are invited to attend the welcome webinar. A zoom link will already be provided within the email with a set date and time. It is important to notify us whether or not you are able to attend by responding to the email with a confirmation of attendance.
-During the welcome webinar, the president of Bit Project will present to you an introduction to Bit Project and the various teams \(developer relations, engineering, people, and marketing\). Then the next step of the process is introduced where every applicant is required to join slack and create a GitHub account. Managers and mentors will give a brief introduction about themselves and welcome the applicants.
+During the welcome webinar, the president of Bit Project will present to you an introduction to Bit Project and the various teams \(developer relations, engineering, people, and marketing\). Then the next step of the process is introduced where every applicant is required to join slack and create a GitHub account. Managers and mentors will give a brief introduction about themselves and welcome the applicants.
-The info session time for the next day will be scheduled at the end of the webinar.
+The info session time for the next day will be scheduled at the end of the webinar.
#### Day 1 \(Friday\):
On this day, applicants will attend the info session. The info session will cover the following listed topics: general breakdown of the week, onboarding presentation, introduction to the team, task explanations, GitHub/GitHub desktop set-up, activities/lab introduction, complete slack set-up, and first-timer task.
-The breakdown just goes over what to expect in the upcoming week with meeting the team, new tasks, and one-on-one meetings.
+The breakdown just goes over what to expect in the upcoming week with meeting the team, new tasks, and one-on-one meetings.
-The onboarding presentation will provide a brief introduction to Bit Project \(as the Welcome Webinar should have already presented this information\), GitHub & GitHub desktop tutorial, introduction to what exactly our curriculum entails with activities and labs.
+The onboarding presentation will provide a brief introduction to Bit Project \(as the Welcome Webinar should have already presented this information\), GitHub & GitHub desktop tutorial, introduction to what exactly our curriculum entails with activities and labs.
-Towards the end of this info session, the managers will double check that the applicants are all on slack and the team manager will provide the applicants with their first-timer task. This first-timer task is meant to introduce each applicant to the team's project, giving them an insight to how the work of a developer on this specific team. Applicants are able to refer to their mentor and team manager for help in this process.
+Towards the end of this info session, the managers will double check that the applicants are all on slack and the team manager will provide the applicants with their first-timer task. This first-timer task is meant to introduce each applicant to the team's project, giving them an insight to how the work of a developer on this specific team. Applicants are able to refer to their mentor and team manager for help in this process.
#### Day 2-3: \(Saturday - Sunday\)
-Throughout the weekend, applicants are expected to finish their first-timer task and become familiar with the use and format of issues on GitHub. Once the task is complete, the applicant will wait for their manager / reviewer to review their work.
+Throughout the weekend, applicants are expected to finish their first-timer task and become familiar with the use and format of issues on GitHub. Once the task is complete, the applicant will wait for their manager / reviewer to review their work.
Applicants are expected to watch the provided webinars that discuss important aspects and values of Bit Project. \(Communication, culture, etc.\)
#### Day 4 \(Monday\):
-On Slack, every team manager should have a Calendly already set-up. Schedule a one-on-one meeting with your team manager.
+On Slack, every team manager should have a Calendly already set-up. Schedule a one-on-one meeting with your team manager.
* [ ] Schedule meeting with Manager
* Schedule a 1:1 meeting through Calendly for Day 8-9
#### Day 5 \(Tuesday\):
-On this day, applicants should focus more on the breakdown and specifics of labs and activities.
+On this day, applicants should focus more on the breakdown and specifics of labs and activities.
-During the one-on-one, the applicant will give the manager feedback on their activity / lab experience if the applicant is given one.
+During the one-on-one, the applicant will give the manager feedback on their activity / lab experience if the applicant is given one.
-Applicants are to send a greeting message into Slack, notifying their team of who they are.
+Applicants are to send a greeting message into Slack, notifying their team of who they are.
#### Day 8-12:
-Within these days, the applicant should be meeting with their team manager. The applicant will be taught how to take meeting notes with GitHub, and will practice taking notes throughout or after the meeting.
+Within these days, the applicant should be meeting with their team manager. The applicant will be taught how to take meeting notes with GitHub, and will practice taking notes throughout or after the meeting.
-They will discuss the onboarding task and the manager will provide feedback. The contributor will then provide feedback on the labs and activities process \(if it is given\). Then the applicant will schedule a one-on-one with a member of onboarding. The link will be provided by the team manager.
+They will discuss the onboarding task and the manager will provide feedback. The contributor will then provide feedback on the labs and activities process \(if it is given\). Then the applicant will schedule a one-on-one with a member of onboarding. The link will be provided by the team manager.
#### Day 12-14:
-The final step of the onboarding process will be completed with a one-on-one meeting between the applicant and with onboarding. Applicant will provide feedback to onboarding about the whole process, and onboarding will ensure that the applicant is ready to be fully integrated into the Bit Project team.
+The final step of the onboarding process will be completed with a one-on-one meeting between the applicant and with onboarding. Applicant will provide feedback to onboarding about the whole process, and onboarding will ensure that the applicant is ready to be fully integrated into the Bit Project team.
diff --git a/teams/engineering/readme-formats.md b/teams/engineering/readme-formats.md
index 21982d8..c9983f2 100644
--- a/teams/engineering/readme-formats.md
+++ b/teams/engineering/readme-formats.md
@@ -474,12 +474,14 @@ To include the md\_content for the step, give the md\_content with a markdown h2
```text
### md_content
```
+
### Hello world in js
+
This is how you do it
-```
-```
+```text
+```
#### Optional Fields
@@ -490,8 +492,11 @@ To include the code snippet for the step, give the code snippet with a markdown
```text
### code_snippet
```
-def pls_work(): return True... maybe
-```
+
+def pls\_work\(\): return True... maybe
+
+```text
+
```
#### Image
@@ -520,21 +525,20 @@ How to install VSCode
### md_content
```
-Hello world in js
-This is how you do it
-```
+Hello world in js This is how you do it
+
+```text
### code_snippet
```
-def pls_work(): return True... maybe
-```
+def pls\_work\(\): return True... maybe
+
+```text
### image
```
-
-
### Concept Format
#### Concept Name \(This is required\)
@@ -570,8 +574,11 @@ Under the hint name, you have to give the step a name with a markdown h2 tag. **
```text
## name
```
+
How to install VSCode
-```
+
+```text
+
```
#### Md\_content \(You need to include this for each step\)
@@ -581,12 +588,14 @@ To include the md\_content for the step, give the md\_content with a markdown h2
```text
## md_content
```
+
## Hello world in js
+
This is how you do it
-```
-```
+```text
+```
#### Optional Fields
@@ -597,8 +606,11 @@ To include the code snippet for the step, give the code snippet with a markdown
```text
## code_snippet
```
-def pls_work(): return True... maybe
-```
+
+def pls\_work\(\): return True... maybe
+
+```text
+
```
#### Image
@@ -625,19 +637,22 @@ Topic1/Module2_test/concepts/
## name
```
+
How to install VSCode
-```
+```text
## md_content
```
-Hello world in js
-This is how you do it
-```
+Hello world in js This is how you do it
+
+```text
## code_snippet
```
-def pls_work(): return True... maybe
-```
+
+def pls\_work\(\): return True... maybe
+
+```text
## image
```
diff --git a/teams/engineering/roles/backend-developer.md b/teams/engineering/roles/backend-developer.md
index 98fdd9a..74c928c 100644
--- a/teams/engineering/roles/backend-developer.md
+++ b/teams/engineering/roles/backend-developer.md
@@ -13,9 +13,9 @@ description: >-
* Experience working with a SQL Database such as PostgreSQL, MySQL, SQLite
* Experience working with SQLAlchemy or some other Python ORM \(PeeWee, Django ORM, etc.\)
* Able to collaborate with other Backend and Frontend Developers to solve technical and architectural problems
-* Experience with developing and maintaining REST APIs
+* Effective communication among colleagues
* Comfortable with working in an Agile development life cycle
-* Ability to communicate and collaborate with other Backend and React developers to
+* Ability to flourish in a remote setting
* Passion for backend development/coding
## Nice-haves
@@ -26,14 +26,6 @@ description: >-
* Developing backend components to improve responsiveness and overall performance for API consumers
* Collaborating with Frontend Developers to design more cohesive code to enhance user experience
-* Optimizing existing backend infrastructure to improve
* Creating code that fits our style and best practice guidelines
-* Running code through a series of load testing to fix existing bugs to enhance the speed of enpoints
-* Documenting/updating endpoints on Postman
-
-
-
-
-
-
+* Updating documentation of routes on Postman and Gitbook
diff --git a/teams/engineering/roles/frontend-architect.md b/teams/engineering/roles/frontend-architect.md
index 196963b..fdb32af 100644
--- a/teams/engineering/roles/frontend-architect.md
+++ b/teams/engineering/roles/frontend-architect.md
@@ -2,28 +2,3 @@
## Requirements
-* Expertise with React or some other frontend framework \(Inferno.js, Vue, etc.\)
-* Fluent with ES6/7 Javascript syntax/concepts \(Asynchronous programming, Destructuring, etc.\)
-* Ability to architect efficient and reusable front-end abstractions and systems that drive complex web applications
-* Comfortable with design principles and ability to apply them to create aesthetically pleasing UI
-* Experience with REST APIs and API First Design
-* Excellent written and verbal communication skills
-* A friendly and welcoming personality
-
-## Nice-haves
-
-* Experience with Postman to test API endpoints
-* Experience with either SQL or NoSQL databases
-* Likes to geek out by making animations with Anime.js
-
-## Responsibilities
-
-* Ability to lead engineering projects from design to implementation to deployment and maintenance
-* Ability to take wireframes and bring them to life with JSX and CSS
-* Creating reusable React components for future use
-* Optimizing web pages for maximum speed to enhance user experience
-* Collaborating with other React.js Developers and Designers to determine the structure and design of components for the LMS
-* Collaborating with Backend developers to determine the necessary data needed to implement components
-
-
-
diff --git a/teams/engineering/roles/react.js-developer.md b/teams/engineering/roles/react.js-developer.md
index 891935f..bdb6ace 100644
--- a/teams/engineering/roles/react.js-developer.md
+++ b/teams/engineering/roles/react.js-developer.md
@@ -30,5 +30,3 @@ description: >-
* Collaborating with other React.js Developers and Designers to determine the structure and design of components for the LMS
* Collaborating with Backend developers to determine the necessary data needed to implement components
-
-
diff --git a/teams/people/README.md b/teams/people/README.md
index 7821c58..2b38e48 100644
--- a/teams/people/README.md
+++ b/teams/people/README.md
@@ -8,9 +8,9 @@ description: >-
## What is the People Team?
-The Bit Project has grown quickly, and plans to continue grow while maintaining our culture and remote working, embracing development, and building scalable people-oriented policies. Our team oversees recruiting and learning and development functions. We are responsible for investing in the engagement and development of members, as people, which first benefits the members, and as a result, the organization as a whole. The People team is about designing work so that you want to be there – present, engaged, and proud of what you do in Bit. In this team, we focus providing members proactive learning materials to make operations easier, especially in the times of change management. Moreover, we focus on on-boarding new members from around the United States. Please do not hesitate to reach out to any People members with questions! In the case of a conflict between the organization and a team member, the People Team is always here to assist you.
+The Bit Project has grown quickly, and plans to continue grow while maintaining our culture and remote working, embracing development, and building scalable people-oriented policies. Our team oversees recruiting and learning and development functions. We are responsible for investing in the engagement and development of members, as people, which first benefits the members, and as a result, the organization as a whole. The People team is about designing work so that you want to be there – present, engaged, and proud of what you do in Bit. In this team, we focus providing members proactive learning materials to make operations easier, especially in the times of change management. Moreover, we focus on on-boarding new members from around the United States. Please do not hesitate to reach out to any People members with questions! In the case of a conflict between the organization and a team member, the People Team is always here to assist you.
-## The Core Objectives of the People Team, Are to:
+## The Core Objectives of the People Team, Are to:
Shift from task-based management to objective-based management \(MBO\) – **Higher productivity, measurable performance results**
@@ -28,9 +28,9 @@ Cross pollination and collaboration – **Build capable managers with fresh idea
## Our Actions and Goals
-As a team, we are always trying to find new ways to improve Bit Project. We want to create a well-rounded for all members. On that notes, we decided to implement webinars for new members in our on-boarding process to allow a smoother transition. We created a training guide on how to be a successful and effective manager at Bit. Additionally, we are constantly creating learning and development guides such as communication, internal feedback, diversity and inclusion, and how to use applications like Github are all provided on this Handbook. Lastly, we try to document as much information to increase our transparency as well as provide you all the materials on how to be successful as Bit Project.
+As a team, we are always trying to find new ways to improve Bit Project. We want to create a well-rounded for all members. On that notes, we decided to implement webinars for new members in our on-boarding process to allow a smoother transition. We created a training guide on how to be a successful and effective manager at Bit. Additionally, we are constantly creating learning and development guides such as communication, internal feedback, diversity and inclusion, and how to use applications like Github are all provided on this Handbook. Lastly, we try to document as much information to increase our transparency as well as provide you all the materials on how to be successful as Bit Project.
-## Responsibilities
+## Responsibilities
* Provide an enriching experience for all members by creating materials for learning and development.
* Maintain appropriate level of process, program, and policy knowledge in order to assist team members.
@@ -42,5 +42,3 @@ As a team, we are always trying to find new ways to improve Bit Project. We want
* Announcing changes and improvements
* Engagement survey administration & implementation.
-
-
diff --git a/teams/people/joining-the-team.md b/teams/people/joining-the-team.md
index af1b159..d38f8a1 100644
--- a/teams/people/joining-the-team.md
+++ b/teams/people/joining-the-team.md
@@ -37,18 +37,18 @@ Once you are on slack, please complete the following tasks:
* [ ] DM Becca Tran to set up a 1:1 Meeting
* [ ] Send an introduction of yourself to the \#newmembers channel
* include:
- * Name
- * Team
- * Major
- * Year
- * Favorite Memory
- * Ex: "Hi! My name is Carl from New York studying at NYU as an Economic major! I am a third year and I am so excited to work you today. I will be joining the best team which is the People Team! My favorite memory this year was going to Disneyland. Can't wait to get to know you guys more!"
+ * Name
+ * Team
+ * Major
+ * Year
+ * Favorite Memory
+ * Ex: "Hi! My name is Carl from New York studying at NYU as an Economic major! I am a third year and I am so excited to work you today. I will be joining the best team which is the People Team! My favorite memory this year was going to Disneyland. Can't wait to get to know you guys more!"
## Day 2
### 3. 1:1 Meeting With the Manager of People
-During your meeting with the Manager \(Becca Tran\), the Manager will go over what exactly the People Team is, the purpose of the team, and what the team does. The Manager will then assign you your tasks, consisting of watching a set of webinars and giving you a case on a workflow issue. This will be taken place over Zoom.
+During your meeting with the Manager \(Becca Tran\), the Manager will go over what exactly the People Team is, the purpose of the team, and what the team does. The Manager will then assign you your tasks, consisting of watching a set of webinars and giving you a case on a workflow issue. This will be taken place over Zoom.
### 4. Watching Our Webinars
@@ -65,13 +65,13 @@ There are three webinars that you must watch: Communication, Team Feedback, and
* [ ] Google Calendar
* [ ] [https://calendar.google.com/calendar?cid=dWNkYXZpcy5lZHVfMGhpZzcwNmdlMWRuZmpsMWVyc3V1YmFyaHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ](https://calendar.google.com/calendar?cid=dWNkYXZpcy5lZHVfMGhpZzcwNmdlMWRuZmpsMWVyc3V1YmFyaHNAZ3JvdXAuY2FsZW5kYXIuZ29vZ2xlLmNvbQ)
-You can access to this by asking for the Becca Tran if the links do not work
+You can access to this by asking for the Becca Tran if the links do not work
## Day 3
-### 5. People Issue Case
+### 5. People Issue Case
-You will be given a scenario regarding an issue with the workflow, diversity and inclusion, internal feedback process, or onboarding. Where you would address the issue and find a solution for it in a proposal \(written\) and you will present it during the follow-up with Becca Tran.
+You will be given a scenario regarding an issue with the workflow, diversity and inclusion, internal feedback process, or onboarding. Where you would address the issue and find a solution for it in a proposal \(written\) and you will present it during the follow-up with Becca Tran.
* [ ] Complete the proposal before the next meeting with Becca Tran
* [ ] Email the proposal to Becca Tran \(rhtran@ucdavis.edu\)
diff --git a/teams/people/onboarding-guides.md b/teams/people/onboarding-guides.md
new file mode 100644
index 0000000..3d22795
--- /dev/null
+++ b/teams/people/onboarding-guides.md
@@ -0,0 +1,4 @@
+# Onboarding Guides
+
+{% page-ref page="../developer-relations/guide-to-being-a-manager/" %}
+
diff --git a/teams/people/recruitment.md b/teams/people/recruitment.md
new file mode 100644
index 0000000..ee410d7
--- /dev/null
+++ b/teams/people/recruitment.md
@@ -0,0 +1,2 @@
+# Recruitment
+
diff --git a/teams/people/recruitment/README.md b/teams/people/recruitment/README.md
deleted file mode 100644
index 8fa369d..0000000
--- a/teams/people/recruitment/README.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# Primary Ed
-
diff --git a/teams/people/recruitment/general-event-volunteer-training.md b/teams/people/recruitment/general-event-volunteer-training.md
index 62a4f6d..f2a3e3b 100644
--- a/teams/people/recruitment/general-event-volunteer-training.md
+++ b/teams/people/recruitment/general-event-volunteer-training.md
@@ -1,9 +1,22 @@
# General Event Volunteer Training
+\*\*\*\*[**General Event Volunteer Training**](https://www.youtube.com/watch?v=QEdVY4sYBAw&feature=youtu.be) **\(Video\)**
+**Table of Contents**
-\*\*\*\*[**General Event Volunteer Training**](https://www.youtube.com/watch?v=QEdVY4sYBAw&feature=youtu.be) **\(Video\)**
+\[Introduction\]\(\#Introduction\)
+[**Student Maturity and Developmental Level**](https://docs.google.com/document/d/1j9sRsnnDl8zejKH-Rbr2Vi06KXZRn-ybCA-Se2FnihM/edit#heading=h.bnudk2mybu8i)
+
+[**Volunteer Expectations**](https://docs.google.com/document/d/1j9sRsnnDl8zejKH-Rbr2Vi06KXZRn-ybCA-Se2FnihM/edit#heading=h.p4fhfis7bpo)
+
+[**UC Davis Rules when Working with Minors**](https://docs.google.com/document/d/1j9sRsnnDl8zejKH-Rbr2Vi06KXZRn-ybCA-Se2FnihM/edit#heading=h.yy8a3u3gehcz)
+
+[**Method of Control**](https://docs.google.com/document/d/1j9sRsnnDl8zejKH-Rbr2Vi06KXZRn-ybCA-Se2FnihM/edit#heading=h.uu4g3o69o1yr)
+
+[**Discipline and Praise**](https://docs.google.com/document/d/1j9sRsnnDl8zejKH-Rbr2Vi06KXZRn-ybCA-Se2FnihM/edit#heading=h.99xuhcfa675q)
+
+[**BitCart Specifics**](https://docs.google.com/document/d/1j9sRsnnDl8zejKH-Rbr2Vi06KXZRn-ybCA-Se2FnihM/edit#heading=h.qh7wdowcoqir)
## **Introduction**
@@ -31,7 +44,7 @@ It all comes down to these three things.
## **UC Davis Rules when Working with Minors**
-Since the events are organized by a UC Davis student organization, we are required to abide by certain school policies. For instance:
+Since the events are organized by a UC Davis student organization, we are required to abide by certain school policies. For instance:
1. Minors will be treated with respect at all times: regardless of race, sex, age, or religion
2. Staff and volunteers must avoid showing affection with minors, not use profanity or tell jokes with innuendos that contain racist or indecent commentary.
@@ -41,9 +54,9 @@ Since the events are organized by a UC Davis student organization, we are requir
1. If students need to go on bathroom breaks, contact your volunteer lead.
6. You must prohibit minors from engaging in inappropriate behavior such as hazing, bullying,
-Example of a Situation: Dodging hugs.
+Example of a Situation: Dodging hugs.
-We expect volunteers to set an example for the students
+We expect volunteers to set an example for the students
## **Method of Control**
@@ -51,7 +64,7 @@ The second thing we need to introduce is a method of control. This involves an a
## **Discipline and Praise**
-The third thing we need to do is establish a fair discipline system. Most teachers have this already implemented in their class and all classrooms are different. Before an activity, ask the teacher how they discipline their students.
+The third thing we need to do is establish a fair discipline system. Most teachers have this already implemented in their class and all classrooms are different. Before an activity, ask the teacher how they discipline their students.
Remember, in order to have effective discipline, the three expectations must be clearly communicated first. Methods of discipline may involve different signals but they are all very similar and typically involves four steps:
@@ -72,12 +85,12 @@ The role of a volunteer is to help teachers and students conduct the activity. A
* Don’t get carried away… Focus on helping students learn and understand various difficult concepts. If you feel there is too much information help make sure key concepts are understood!
* If you feel uncomfortable with any of the concepts, check out the Learn More page at the end of each designated activity. Feel free to ask other volunteers for help.
-Make sure you watch two other videos if you haven’t done so already:
+Make sure you watch two other videos if you haven’t done so already:
1. Activity: This video explains the activity to be done at your event!
-2. “BitCart Logistics”
+2. “BitCart Logistics”
-The “BitCart Logistics” will contain information on:
+The “BitCart Logistics” will contain information on:
* Logistics for general events
* Location - transportation options
diff --git a/teams/people/recruitment/how-to-be-a-volunteer-lead.md b/teams/people/recruitment/how-to-be-a-volunteer-lead.md
index 12f5818..135bd7a 100644
--- a/teams/people/recruitment/how-to-be-a-volunteer-lead.md
+++ b/teams/people/recruitment/how-to-be-a-volunteer-lead.md
@@ -1,6 +1,36 @@
# How to Be a Volunteer Lead
-[**How to Be a Volunteer Lead Training**](https://www.youtube.com/watch?v=QEdVY4sYBAw&feature=youtu.be) **\(Video\)**
+\*\*\*\*[**How to Be a Volunteer Lead Training**](https://www.youtube.com/watch?v=QEdVY4sYBAw&feature=youtu.be) **\(Video\)**
+
+**Table of Contents**
+
+[**Introduction**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.ysk5pi603r3r)
+
+[**What Volunteer Leads Do**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.hmuk041wrme6)
+
+[**Working with Students**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.g67v3nmtahuv)
+
+[**Mood**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.1kyjv7u995pw)
+
+[**Verbal Language**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.7bxdvwa981ax)
+
+[**Body Language**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.fedop5pnqy7w)
+
+[**Delivery**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.4m6ei14peo5w)
+
+[**Situations**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.l8a4z1b8wjsf)
+
+[**Starting off an Event**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.w7hdl0tyzdsk)
+
+[**Opening an Activity**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.8ofv984l8dj7)
+
+[**Activity**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.yee5jn48up98)
+
+[**Cleaning Up**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.s2uaovhqtjvr)
+
+[**BitCart**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.k59vfbffwmk7)
+
+[**BitQuest**](https://docs.google.com/document/d/1A2wCG85mgUUvhf9yfHxBEXmuSOJFvObtFOG1TfgRI5s/edit#heading=h.dvkj4a86qho8)
## **Introduction**