Week 2A

[vincenzocoia]

Some stuff to go on Week 2A's page.

• Optional reading for Tuesday's class: https://medium.com/@ayman/wysiwyg-is-dead-d225276ed53
  • An entertaining and concise argument against using "WYSIWYG" editors like Microsoft Word.

cc @almas2019

[almas2019]

@vincenzocoia Based on your comments from slack:

Almas -- the things in your first message are all up in the air at the moment. Would you feel comfortable coming up with a design for the week that you think is most appropriate? I'm confident that you'll be able to come up with a great design. Then, could you report back to me with your ideas? So, in other words: what should be done in the "demonstration" part of class on Tuesday and Thursday? This should be 20-30 minutes, as a guideline. to what extent will they work on Worksheet 1-A on Tuesday and Thursday after the instructor-lead demonstration? to what extent will they work in their teams on their project on Tuesday and Thursday after the instructor-lead demonstration? to what extent will they work in their teams on their project outside of class? To help you make these decisions, you can use the following guidelines: students should spend about 6 hours per week on STAT 545 related things: 3 hours in class, 1-1.5 hours of pre-reading, and 1.5-2 hours on coursework outside of class.

This is the rough idea I have

Tuesday:

Preclass:

No lecture worksheet per se today (there will be a document to include instructions to these activities), the following should be completed:

• A github account
• Delivarable: A link to your personal GitHub repo & to your group repo. --> Put on Canvas?
  • Include instructions in a separate worksheet that is adapted from the workbook : Adapting the material in Topic 2: GitHub into a document that students can follow through, but only until (and including) "1.5.3 GitHub as cloud storage - Activity". Include a during class section for Git setup, hopefully I will complete this today as a Rmarkdown for reference (not to be completed)

    During Class:

    15 min. : Github overview/demonstrate-

  • Demo the typical workflow (~8 min)
  • Students follow the typical workflow activity in the repo that they created as pre-work (~5-6 min)

15 min: + Giving group partners the chance to interact in a breakout room, introduce themselves & create a teamwork document and do the following, TAs move around or ask questions

• Branching
• Opening issues
• Open and merge a pull request
  • Should forking and cloning be included or left to 545B?

5-10min : Break/buffer

50 min: Worksheet 1A Section 1

Thursday's Class : Topic: Rmarkdown and Reproducibility

cat(thurs_date_pretty)

From today's class, students are anticipated to be able to:

Prepare for Class

• Watch the STAT 545 Video Series: Class r thurs_class_num

During Class

• Output formats, markdown basics, and cheatsheets (~30 min) - a mix of explanations / in-class demo
• Lecture worksheet (~30 min) - in breakout rooms of 5/6 people
• Finish & style R markdown for the teamwork document + push it to the group repo (~30 min) - in breakout rooms with group partners
  • Basically Complete Worksheet 1A section 2 on R markdown

[dy-lin]

Here is some feedback:

Include a during class section for Git setup, hopefully I will complete this today as a Rmarkdown for reference (not to be completed)

• Since 'output formats' is on Thursdays class, I think part of the demo should be how to do a basic knit of your Rmarkdown for reference
• Additionally, maybe a bit about how to use RStudio, and the basics of R (not sure if this is covered in the pre-class videos or readings), but a lot of students don't actually know that install.packages() has to come before library()

Github overview/demonstrate

• I would suggest staying with RStudio for learning git and using it as a client instead of the command-line

Branching

• talk about remote vs local branches (e.g. origin?)
• are they creating the branch on the website or via RStudio?

Opening issues

• this wasn't something that was specifically taught, but I really enjoyed using the - [ ] and - [x] markdown feature (checkbox) in GitHub Issues for collaborative projects-- it's live, meaning that any member of the group repo can check off tasks as they're done regardless of who made the original comment on the issue using the checkboxes (see below)

• [ ] this checkbox can be checked by anyone

Open and merge a pull request

• Maybe talk about how to deal with merge conflicts as well (I see that it's in the guidebook, but wasn't listed above)
• Merging branch into master vs. merging master into branch

Should forking and cloning be included or left to 545B?

• Assuming that the curriculum for 545B is similar to 547M, I think it's best to leave this once they have more experience using git

Output formats, markdown basics, and cheatsheets (~30 min) - a mix of explanations / in-class demo

• if html is one of the output formats, maybe touch on GitHub Pages
• I think the guide book links quite a few 'cheatsheets'-- it would be cool if we could collect them this year and maybe add a page under Tutorials so they're easier to find! (It would be nice if we could do this with all linked 'external' links/guides too, to compile them into one location so they're easy to look for/back on)
• markdown-- could also emphasize that a lot of these ones (quoting, code blocks and inline code) are available in Slack messaging as well, and make code/responses a lot easier to read

cat(thurs_date_pretty)

• what is this for?

[vincenzocoia]

@almas2019 Thanks for your notes! Just a workflow comment: I can see that you've added comments based on pre-existing week2a notes, but it's hard for me to distinguish between what was originally on the week2a document and your notes. Using the comment > feature of markdown is really useful here!

Comments on the above are given below, under "Comments on Week 2A outline"

"What should happen now..." is for anyone interested.

What should happen now...

Here's what should happen now:

• Update the week2a.Rmd document using the input I see from @sciclic @almas2019 and @dy-lin, and based on my comments below.
• Split the class into groups of 2-3 for the troubleshooting project. Perhaps put students in opposite time zone together? (I think there are 3)
• Make a "Collaborative Project Milestone 1 package" (I moved the troubleshooting documents to source and release, like the worksheets, although these don't use nbgrader)
  • Double-check for mistakes in the troubleshooting documents.
  • Make sure that instructions are given for taking charge of their repos.
    • Making a teamwork document, a README, and perhaps an Issue each, where each student introduces themselves to the other student(s), and the other student(s) reply. And, no branching for this milestone, maybe??
    • I'm not sure whether this belongs as a tutorial under the "Tutorials" section of the website, or as an activity in Milestone 1 -- I'm leaning towards the latter.
  • Check for do-ability: if "taking control of your repos" can be done in class, then the timing should still work out if we keep the troubleshooting document as-is.
  • Make repos for the students' collaborative projects by starting a new "assignment" under the STAT 545 GitHub Classroom Org -- I think there's a teamwork option.

My intent is to just buckle down and do it all tomorrow. I wouldn't turn down help, but I totally don't expect anyone to do anything on a Sunday! (Victor is away, anyway)

Comments on Week 2A outline

Prework Make a github account

Making a GH account is no longer relevant, since they would have done that last week.

Include instructions in a separate worksheet that is adapted from the workbook

I think the best way to do this is to include it in the Tutorials section of the website.

Since 'output formats' is on Thursdays class, I think part of the demo should be how to do a basic knit of your Rmarkdown for reference

I think git and GitHub are going to dominate Tuesday. I'm hesitant to throw this into the mix. I think:

• Write plain md files for now, with no formatting, for their README and teamwork document -- for Milestone 1.
• Practice with cloning, pushing, and pulling.
• How they work on the troubleshooting document will depend on whether we get them to branch this week or not. I'm still on the fence about branching this week.

Additionally, maybe a bit about how to use RStudio, and the basics of R (not sure if this is covered in the pre-class videos or readings), but a lot of students don't actually know that install.packages() has to come before library()

Yes. Maybe. We're in a pickle because this was supposed to be covered last class.

I would suggest staying with RStudio for learning git and using it as a client instead of the command-line

100% -- maybe this is our ticket to introducing RStudio, but not R yet.

this wasn't something that was specifically taught, but I really enjoyed using the - [ ] and - [x] markdown feature (checkbox) in GitHub Issues

Great idea. I think this should appear in the "Milestone 1 instructions".

Maybe talk about how to deal with merge conflicts as well

Yes. Definitely important and they should get some instruction on this in some form.

Should forking and cloning be included or left to 545B?

Cloning should be in Week 2A. I don't see forking as being significant enough to re-introduce as a topic, especially in 545B. I think it would be a good "choose your own adventure" topic for lecture 13. (note added to Asana)

if html is one of the output formats, maybe touch on GitHub Pages

This might be too peripheral for an already-swollen Week 2A. Perhaps useful for "choose your own adventure", or 545B.

I think the guide book links quite a few 'cheatsheets'-- it would be cool if we could collect them this year and maybe add a page under Tutorials so they're easier to find! (It would be nice if we could do this with all linked 'external' links/guides too, to compile them into one location so they're easy to look for/back on)

I think this might already be in the "Resources" section of the website?

markdown-- could also emphasize that a lot of these ones (quoting, code blocks and inline code) are available in Slack messaging as well, and make code/responses a lot easier to read

Yeah! I think this would be good to add as a Slack message on Thursday!