Assignment 5b o234

[wvictor14]

Addresses #83

• [x] Option A
• [x] Option B draft
• [x] Option C draft

Will reread sometime this weekend or on monday. Will probably push a few more small changes but I think most of the structure is there.

I didn't really put an option for "Create an entirely new app/package" from scratch. I was planning to... but I just started writing and this is what came out. I'll see if I fit that in when I reread this...

[wvictor14]

I think it's very clear what is mandatory/required. I know that the students have 3 options, but how does the workload compare between improving the app/package and the string assignment? @dy-lin

That's one reason I wrote 5 changes are required for the app instead of 3, because it feels like the R package option is hefty... But maybe with the "high-level" changes @vincenzocoia suggested, this might not be an issue.

[wvictor14]

@vincenzocoia

It sounds like you want me to remove some of the specific instructions, and let the student's determine for themselves what is adequate amount of effort/work/detail.

I'm just wary of leaving intentionally non-specific instructions. Before I start editing, can you help me by providing an example of what kind of requirement you're looking for?

For example, should I change this:

1. Create a list of 3 improvements or fixes that you plan to address in this updated version. Put each distinct change (or set of changes) as a new github issue, and also briefly describe how you propose to address each issue. Some examples of possible types of issues:
   • errors or bugs that needs to be fixed
   • added functionality
   • improved documentation

To something like this:

1. Create improvements to your R package that you plan to address in this updated version. If appropriate, describe the improvements using Github Issues.

[vincenzocoia]

let the student's determine for themselves what is adequate amount of effort/work/detail.

No, we definitely need to provide guidance here.

I'm not sure I can fully articulate the details of the approach I'm suggesting. And ultimately, I don't have evidence to suggest one way will work better than the other -- we'll need to test drive the assignment to get that info. So, I'm happy with whatever you ultimately decide to do here.

Roughly, what I'm imagining is:

1. Not requesting 3 Issues, but rather at least one pull request. They should still definitely describe how their changes amount to at least 3 features.
2. Grading in terms of their product overall, instead of individually looking at each change. Rubrics might look something like: (a) Basic functionality, as requested in the original assignment. (b) Code mastery (c) Design: is your app/package designed in a user-friendly way? Or are there some rough patches that interrupts the user's flow?

I can look into other examples of rubrics from other projects that might be useful, if you'd like!

But again, I'm ultimately happy with what you decide here. Just providing suggestions.

[wvictor14]

Just going to summarize before I start working on implementing changes. I'm planning to finish at the end of today.

Option B:

• More high level instructions, allow more freedom in how students want to improve their packages
• Allow creating package from scratch instead of improving on their existing one

Something like:

Your starting point would satisfy the requirements of Assignment 3-B. This means implementing feedback, and ensuring your starting point doesn't break with further development. It also means, if you want to start from scratch, you'll need to produce the equivalent of Assignment 3-B before moving on to Assignment 5-B.

• Do not require exactly 3 changes / improvements, but still require documentation of changes
• some guidance if developing a data package: prepare for cran submission, comprehensive EDA vignette, additional data
• "appropriate usage"
• Adjust rubric to:

a) Basic functionality, as requested in the original assignment. (b) Code mastery (c) Design: is your app/package designed in a user-friendly way? Or are there some rough patches that interrupts the user's flow?

Option C:

• More high level
• add same blurb about creating packages from scratch
• Not exactly X number of features/ improvements
• adjust rubric to something like:

The purpose of the app is clearly indicated on the app. There's enough documentation to know how to use the app. Ideally, one doesn't have to read all that much to use the app at a superficial level. The app is designed in a way that makes it easy to use and fulfill the app's purpose. Demonstrated code mastery.

• add examples - widget to reset to default

[dy-lin]

I think an option of 'building a shiny app' from scratch might be of interest to some who took STAT545A, specifically converting their mini-data-analysis into a shiny app?

[wvictor14]

OK this version is updated with feedback implemented @dy-lin @vincenzocoia . If I had more time, I would organize the r package option more like the shiny app section. But I think it's reasonably clear still...

[vincenzocoia]

Thanks, @wvictor14 ! I'll finish the strings part of the assignment tomorrow, and we can launch it then.

[vincenzocoia]

@dy-lin @wvictor14 I'm finished Option A of the assignment. If you have a moment, please take a look. I deliberately didn't give a detailed breakdown of marks for each exercise, so that we can have more flexibility when grading. I think we should launch this assignment sometime today

[vincenzocoia]

(Version needs to be finalized at 1.0.0 before launching)

[wvictor14]

@vincenzocoia I think it looks fine. Maybe somewhere stating that they need to use tools described in class? e.g. stringr, regex, paste0().. etc.? I think at the top would be a good place:

Complete the following two exercises using concepts and tools covered in class (i.e. stringr, regex, paste0(), ...etc.)