search

DOI-USGS / ds-pipelines-targets-3-course

Many-task pipelines using targets
Other
4 stars 6 forks source link

Tweak instructions in course to provide fewer pointers? #14

Open hcorson-dosch-usgs opened 3 years ago

hcorson-dosch-usgs commented 3 years ago

In taking the course myself and acting as a reviewer, I've been wondering if some of the instructions in the pipelines-III course hold the course taker's hand a bit too much. In many cases, when a new concept is introduced the coding steps are clearly noted and/or the code is provided and the taker is asked to copy and paste that code. I was wondering if tweaking some of the instructions to be more hint-like, or to merely point people in the right direction would give the course takers a bit more time to sit with the concepts and get the feel of how to implement them. I do, of course, acknowledge that a lot of content is introduced in this course, and that we don't want to make the course tasks too overwhelming or frustrating, or leave the takers discouraged. And as well, as Lindsay pointed out, the more challenging the course, the greater the likelihood that the reviewer will need to spend more time reviewing code, which, although interaction is good, could limit the ability/willingness of others outside this group to lead this course.

jds485 commented 3 years ago

I second this thought. For the checkbox comments and code chunks, I tried to ignore their contents and do the task myself, then went back and looked at the checkboxes and code to make sure I did everything as intended. That approach worked well, and it was useful to have the steps really well documented as a check.

On the comment about code reviewing, I felt for many issues that a PR review was not necessary because all the steps were outlined in the bot-issued comments. Maybe the frequency of PRs can be reduced? I don't have specific issues as examples, but could go back and look

hcorson-dosch-usgs commented 3 years ago

On the comment about code reviewing, I felt for many issues that a PR review was not necessary because all the steps were outlined in the bot-issued comments. Maybe the frequency of PRs can be reduced? I don't have specific issues as examples, but could go back and look

Yes, a number of the PR reviews (3-states, static-branching, splitters, appliers, etc.) have no or minimal changes beyond those laid out in the issues themselves, so it doesn't necessarily feel like a full PR review is necessary, particularly as the PR reviews can slow the taker's progress if the reviewer isn't immediately available.

shamshaw commented 3 years ago

I came in to this pretty rusty in R as I mostly programmed in Matlab previously and I found the level instructions just about right. I think if I was coming in stronger in R, I might have felt it was overly guided. Maybe can add some toggles/accordians to hide content by default and if someone needs a hint they can expand it.