You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Before developing and modifying this workshop, please read through the presenter and developer protocolcarefully and refer back to it regularly as you work.
General issues to be addressed
[Priority] Specific to adapting workshops to a remote framework:
Fit this workshop to a 3-hour format. The duration of this workshop should be ~3 hours (including exercises and one or two breaks of 5 minutes; excluding longer breaks). To fit this format, please add, edit, or hide slides from existing workshops. You can begin by hiding repetitive examples, non-essential slides, or some of the additional advanced slides that are included at the end of some workshops. Some workshops will be more difficult to shorten than others, due to their subject matter. It is not a problem to let these workshops run slightly over 3 hours to guarantee accurate and complete information. (Use your judgment). DO NOT delete slides. Use the instruction: hidden_remote tag. See an example below:
---
instruction: hidden_remote
# Slide title: I love statistics!
### Content: Amazing!
---
Develop new or adapt current exercises to better suit the remote workshop format and the use of breakout rooms. Exercises should be informative and engaging. Remember to leave time for students to work through exercises and ask questions. Refer to these guidelines to find suggestions of exercises promoting active learning. You may use additional resources to create the exercises.
Specific to slide structure, grammar and style
Ensure code is working correctly and that code matches workshop presentation. Continue to check this as you make changes.
Proofread correcting spelling, grammar, or punctuation errors.
Look for and correct the content of slides that overflow the screen.
Look for and correct prose that mentions function names, object names, package names and code chunks that do not use backticks.
Look for and correct unnecessary abbreviations (e.g. use do not instead of don’t).
Correct unnecessary long sentences.
Ensure that the slides are written in a consistent style, which helps with the flow of workshops and student understanding. This is especially important when working collaboratively with other developers.
Include presenter notes to the slides you modify. You can write notes for yourself to read in the presenter mode (press the keyboard shortcut p). These notes are written under three question marks ???. See the example below:
---
The content of this workshop is essential for your graduate studies.
???
Note: _The presenter should sing this slide to the participants_.
---
Specific to the translation of this workshop
Add and translate the modified content to the French version of the workshop.
Proofread and correct spelling, grammar and punctuation errors.
The control flow section covers a lot of different tools, making the structure seem a bit like a big list of possible things to use, which might be overwhelming. This section might benefit from some kind of roadmap to let participants know what is coming in the control flow section. This would mean making subsections, including a header slide or some other visual marker for each subsection, to mark the beginning and end of each topic (e.g. for loops).
Make sure that all instances of for, if, while, etc. are written as code when mentioned in the text (when talking about loops), to avoid confusion.
De-clutter slides, e.g. by simplifying or removing text, breaking cluttered slides up into multiple slides, using bullets or numbered lists, or by improving spacing between lines. Animating line-by-line (using incremental slides --) could also help, but this is not essential.
This is not necessarily a priority for Fall 2020, but error handling is an important part of writing functions. A short section about error handling, and perhaps how to use tryCatch(), would be beneficial.
Specific to this workshop: additional slide-by-slide comments
In current slide 10 (about 'Control flow'), the sentences "Why is it advantageous to have structured programs?" and "This means increased productivity" is too close to the topics. Use <br> to separate it from the text. Follow similar practices through the slides.
For the sake of consistency, include curly brackets after the expressions within the 'Representing structure' slide (currently, slide 12), as in: if() { } and if() { } else { }. Do the same for the iterative portion.
Use incremental slides with (--) to present the content of the 'Decision making' (currently, slide 13).
Within the "What if you want to test more than one condition?" slide (currently, slide 14), add () to the ifelse(). Follow this same procedure for similar situations throughout this workshop (e.g. slide 16, 23, ).
Within the "What if you want to test more than one condition?" slide (currently, slide 14), add arguments to the ifelse() block.
Within the "Nested if else statement" slide (currently, 15), add explanation to this context. A small sentence should be enough. When transforming this flowchart following the recomendations of issue #x, it could be appropriate to split the content in two columns, with the flowchart appearing on the right.
Within the "Challenge 1 - Solution" slide (currently, slide 18), add space between the } and else
The "Beware of R’s expression parsing!" (currently, slide 19) seems misplaced, because participants have just done a challenge that covered this subject. This slide could come before the challenge, but ideally, there should be an earlier indicator about the importance of curly brackets.
The for() loop slide (currently, 13) begins by discussing about the letter i, but this variable is not used in the examples below.
The example within the "for() loop" (currently, slide 25) could come in two columns and a short written explanation should be given to what is going on. In addition to this, the output for the chunk should be displayed in this slide, preferrably as an incremental slide, which would allow the presenter to interact with the participants, asking them what they expect to be the output of each one of those blocks to be.
The examples within the "for() loop" slide (currently, slide 26) should be displayed separately and should present their outputs.
The tips within the "for() loop" slide (currently, slide 27) should have their outputs and sepatered across two columns and in incremental or different slides. One may opt to
The Challenge 3: Solution" slides (currently, slide 44 and 45) could really use of an incremental explanation, i.e. separating the explanation across blocks.
Slide #70: "Keep a clean and nice code" - Mention that in RStudio, Cmd + I or Ctrl + I indents highlighted code automatically
Checkout
Only close this issue after all cases have been ticked and verified.
The text was updated successfully, but these errors were encountered:
- Slide-by-slide comments are addressed.
- Roadmap for control flow is added throughout the slides where needed.
- Some slides are turned into incremental slides.
- For the sake of consistency, spaces within the codes or between the lines are consistently fixed.
- Spelling, grammar, and punctuations are corrected.
- Some presenter notes are added as to how fit the workshop to 3-hour format (passing over some slides more rapidly without hiding any slides).
- A final group exercise is developed to wrap up.
* Note: Issue #1 (reproducible flowcharts) is not a part of these changes.
Before developing and modifying this workshop, please read through the presenter and developer protocol carefully and refer back to it regularly as you work.
General issues to be addressed
[Priority] Specific to adapting workshops to a remote framework:
instruction: hidden_remote
tag. See an example below:Specific to slide structure, grammar and style
Ensure code is working correctly and that code matches workshop presentation. Continue to check this as you make changes.
Proofread correcting spelling, grammar, or punctuation errors.
Look for and correct the content of slides that overflow the screen.
Look for and correct prose that mentions function names, object names, package names and code chunks that do not use backticks.
Look for and correct unnecessary abbreviations (e.g. use do not instead of don’t).
Correct unnecessary long sentences.
Ensure that the slides are written in a consistent style, which helps with the flow of workshops and student understanding. This is especially important when working collaboratively with other developers.
Include presenter notes to the slides you modify. You can write notes for yourself to read in the presenter mode (press the keyboard shortcut
p
). These notes are written under three question marks???
. See the example below:Specific to the translation of this workshop
Add and translate the modified content to the French version of the workshop.
Proofread and correct spelling, grammar and punctuation errors.
Correct unnecessary long sentences.
Specific to this workshop
Solve issue Improve reproducibility issues within this workshop: workflow figures #1
The control flow section covers a lot of different tools, making the structure seem a bit like a big list of possible things to use, which might be overwhelming. This section might benefit from some kind of roadmap to let participants know what is coming in the control flow section. This would mean making subsections, including a header slide or some other visual marker for each subsection, to mark the beginning and end of each topic (e.g.
for
loops).Make sure that all instances of
for
,if
,while
, etc. are written as code when mentioned in the text (when talking about loops), to avoid confusion.De-clutter slides, e.g. by simplifying or removing text, breaking cluttered slides up into multiple slides, using bullets or numbered lists, or by improving spacing between lines. Animating line-by-line (using incremental slides
--
) could also help, but this is not essential.This is not necessarily a priority for Fall 2020, but error handling is an important part of writing functions. A short section about error handling, and perhaps how to use
tryCatch()
, would be beneficial.Specific to this workshop: additional slide-by-slide comments
<br>
to separate it from the text. Follow similar practices through the slides.if() { }
andif() { } else { }
. Do the same for the iterative portion.--
) to present the content of the 'Decision making' (currently, slide 13).()
to theifelse()
. Follow this same procedure for similar situations throughout this workshop (e.g. slide 16, 23, ).ifelse()
block.}
andelse
for()
loop slide (currently, 13) begins by discussing about the letteri
, but this variable is not used in the examples below.for()
loop" (currently, slide 25) could come in two columns and a short written explanation should be given to what is going on. In addition to this, the output for the chunk should be displayed in this slide, preferrably as an incremental slide, which would allow the presenter to interact with the participants, asking them what they expect to be the output of each one of those blocks to be.for()
loop" slide (currently, slide 26) should be displayed separately and should present their outputs.for()
loop" slide (currently, slide 27) should have their outputs and sepatered across two columns and in incremental or different slides. One may opt toCmd + I
orCtrl + I
indents highlighted code automaticallyCheckout
The text was updated successfully, but these errors were encountered: