fix the project milestones

class/milestone1.md

@@ -4,9 +4,8 @@ In this milestone, you will set-up your project for development and submit a das
 
 ## 1. Submission Instructions
 
-- In the [UBCO-MDS GitHub organization](https://github.com/ubco-mds-2021-labs) on github.com, setup a public repository with a reasonable name for your project.
-    - We need a public github.com repo for deployment. This will also make it easy to share a link to your work as part of your portfolio.
-    - This also keeps milestone requirements separate from your actual code-base. You will be making Github releases of your own repository rather than committing to the milestone repository.
+- We need a public github.com repo for deployment. This will also make it easy to share a link to your work as part of your portfolio. Name your repo something memorable.
+- Use the same repo for Milestone 1 and 2 for your python Dashboard.
 - Pick a suitable licence. MIT and BSD-3 are common good options for open source projects. [The carpentries has a short primer on licenses](http://swcarpentry.github.io/git-novice/11-licensing/index.html) (optional read).
 - You will submit your repos on Gradescope, as usual.
 

class/milestone2.md

@@ -6,9 +6,8 @@ You don't need to implement all the feedback you received from your TA yet, but
 
 ## 1. Submission instructions
 
-- In the [UBCO-MDS GitHub organization](https://github.com/ubco-mds-2021-labs) on github.com, setup a public repository with a reasonable name for your project.
-    - We need a public github.com repo for deployment. This will also make it easy to share a link to your work as part of your portfolio.
-    - This also keeps milestone requirements separate from your actual code-base. You will be making Github releases of your own repository rather than committing to the milestone repository.
+- We need a public github.com repo for deployment. This will also make it easy to share a link to your work as part of your portfolio. Name your repo something memorable.
+- Continue using the same repo as Milestone 1 for your python Dashboard.
 - Pick a suitable licence. MIT and BSD-3 are common good options for open source projects. [The carpentries has a short primer on licenses](http://swcarpentry.github.io/git-novice/11-licensing/index.html) (optional read).
 - You will submit your repos on Gradescope, as usual.
 

class/milestone3.md

@@ -7,18 +7,17 @@ You will also give feedback to another group on their dashboard.
 
 ## 1. Submission instructions
 
-- In the [UBCO-MDS GitHub organization](https://github.com/ubco-mds-2021-labs) on github.com, setup a public repository with a reasonable name for your project.
-    - We need a public github.com repo for deployment. This will also make it easy to share a link to your work as part of your portfolio.
-    - This also keeps milestone requirements separate from your actual code-base. You will be making Github releases of your own repository rather than committing to the milestone repository.
+- We need a public github.com repo for deployment. This will also make it easy to share a link to your work as part of your portfolio. You will get a new template repo for your R dashboard, name your repo something memorable, keep the name the same as Milestone 1 & 2, but just add R.
+- Use the same repo for Milestone 3 and 4 for your R Dashboard.
 - Pick a suitable licence. MIT and BSD-3 are common good options for open source projects. [The carpentries has a short primer on licenses](http://swcarpentry.github.io/git-novice/11-licensing/index.html) (optional read).
 - You will submit your repos on Gradescope, as usual.
 
-### Create a new github.com repo for your dashr project
+### Create a new github.com repo for your dashr project (Accept a new GH Classroom link)
 
 - You will create a new repo for this project
 - Name it the same as your Python dashboard repo plus a `-R` suffix so it is easy to find.
     - `your-previous-repo-name-R`
-- Copy over your contributing guidelines, code of conduct README file, and the necessary data files.
+- Copy over your contributing guidelines, code of conduct, teamwork contract, README file, and any data files.
     - Update your README with a link to the deployed R dashboard and a new image/gif of the R dashboard in action.
 
 ### Tips for working collaboratively on GitHub

class/milestone4.md

@@ -10,19 +10,11 @@ We will also try to give recommendations during the lab
 on how you can improve your app.
 
 ## 1. Submission instructions
-rubric={mechanics:4}
 
-- [Click here to view a description of the rubrics used to grade the questions](https://github.com/UBC-MDS/public/tree/master/rubric).
-
-### Canvas submission
-
-- Once you have finished the work for this milestone
-  **you must create a release on GitHub.com before the submission deadline.**
-    - Please [read the GitHub documentation on how to create a release via the online interface]( https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/releasing-projects-on-github). Name your release with the respective milestone name.
-    - We will grade all files in the repo at the state they were in when you created the release.
-      This means that you can continue to make changes in the repo without worrying about messing up your grading for the previous milestone.
-- **The only thing you need to submit to Canvas is a link to your Github release**
-    - Optionally include a link to an auto-deployed Heroku PR (see section 6).
+- We need a public github.com repo for deployment. This will also make it easy to share a link to your work as part of your portfolio. You will get a new template repo for your R dashboard, name your repo something memorable, keep the name the same as Milestone 1 & 2, but just add R.
+- Use the same repo for Milestone 3 and 4 for your R Dashboard.
+- Pick a suitable licence. MIT and BSD-3 are common good options for open source projects. [The carpentries has a short primer on licenses](http://swcarpentry.github.io/git-novice/11-licensing/index.html) (optional read).
+- You will submit your repos on Gradescope, as usual.
 
 ### Tips for working collaboratively on GitHub
 
@@ -39,7 +31,6 @@ rubric={mechanics:4}
       or fork the repo and work on a branch in your own fork.
 
 ## 2. Deployment on Heroku
-rubric={accuracy:3}
 
 - Deploy your app on Heroku
   and **include the link to your deployed dashboard clearly visible near the top of your README**.
@@ -61,7 +52,6 @@ rubric={accuracy:3}
   there should not be a blue debug button on the page your target audience will visit!
 
 ## 3. Tie it all together and deliver a production ready app
-rubric={accuracy:10, quality:5, viz:20}
 
 - You are creating your production-ready dashboard this week!
 - This milestone's grading will be more focused on the final stage of your app
@@ -94,51 +84,30 @@ rubric={accuracy:10, quality:5, viz:20}
         - If I have time during the break, I will use these to make a resource where you can easily find each others dashboards without searching through the public GitHub repos directly. I think this will be useful to reference back to for capstone and later. You can DM me on slack if your group does not want to be part of this for some reason.
 
 ## 4. Reflection
-rubric={reasoning:6}
-
-In this section,
-your group should document on what you have implemented in your dashboard so far
-and explain what is not yet implemented.
-It is important that you include what you know is not working in your dashboard,
-so that your TAs can distinguish between features in development and bugs.
-Since this is the last milestone,
-you really need to motivate well
-why you have not chosen to include some feature
-that you were planning on including previously.
-
-This week it is suitable to include thoughts
-on the feedback you received from your peer and/or TA,
-e.g.
+
+In this section, your group should document on what you have implemented in your dashboard so far and explain what is not yet implemented.
+It is important that you include what you know is not working in your dashboard, so that your TAs can distinguish between features in development and bugs.
+Since this is the last milestone, you really need to motivate well why you have not chosen to include some feature that you were planning on including previously.
+
+This week it is suitable to include thoughts on the feedback you received from your peer and/or TA, e.g.
 
 - Has it been easy to use your app?
 - Are there reoccurring themes in your feedback on what is good and what can be improved?
 - Is there any feedback (or other insight) that you have found particularly valuable during your dashboard development?
 
-This section should be around 300-500 words
-and the `reflection-milestone4.md` document should live in your GitHub.com repo
+This section should be around 300-500 words and the `reflection-milestone4.md` document should live in your GitHub.com repo
 in the `doc` folder.
 
 ## 5. Document your functions' functionality (Optional)
-rubric={accuracy:1}
 
 You have all already written good docstring for your functions, right???
-Well then,
-congrats!
-Your good habits have been awarded with free points in this lab.
-If not,
-this is your chance to remedy the situation.
-Write proper docstrings for all functions,
-including a description of what the function parameters do,
-as you have learnt in previous courses.
+Well then, congrats!
+If not, this is your chance to remedy the situation.
+Write proper docstrings for all functions, including a description of what the function parameters do, as you have learnt in previous courses.
 Clear comments where needed in the code is also a plus.
 
 ## 6. Setup app reviews with Heroku (Optional)
-rubric={accuracy:1}
-
-Heroku has a neat functionality where you can set it up
-to atomically deploy branches when PRs are opened on GitHub.
-This way you can test the dashboard live while reviewing a PR
-without downloading your collaborator's branch and running it locally.
-[Set up your repo accordingly](https://devcenter.heroku.com/articles/github-integration-review-apps)
-and create at least one PR that triggers an auto-deployment.
-Link this PR in `canvas-submission.html`.
+
+Heroku has a neat functionality where you can set it up to atomically deploy branches when PRs are opened on GitHub.
+This way you can test the dashboard live while reviewing a PR without downloading your collaborator's branch and running it locally.
+[Set up your repo accordingly](https://devcenter.heroku.com/articles/github-integration-review-apps) and create at least one PR that triggers an auto-deployment.