Assignment 5-B vision

[vincenzocoia]

@wvictor14 Here's where I'll write my vision for Assignment 5-B.

I have a few pieces of the vision, based on today's discussions, but I'll elaborate more later.

• Assignment should have three options: (1) a "default" option that works with stringr and regex, (2) if they are keen on further developing their R package (started in Assignment 2-B), they can do so, and (3) if they are keen on developing their shiny app (started in Assignment 3-B), they can do so.
• Options for further developing the R package:
  • They could simply just add more functionality.
  • Impressive would be if they make an S3 object oriented package.
  • Contribute to another R package, like broom.

[vincenzocoia]

Maybe a fourth option would be inspiring to students: (4) contribute to an open source analysis or R package or shiny app.

Maybe this can generally be about contributing to the R community. Maybe they can be graded on their impact somehow. Other examples:

• Present a topic in a community group like R Ladies or the UBC study group.
• Contribute to Stack Overflow's R topics.

The one unfortunate thing about this is that, if we do decide to add this option, it would have sure been nice to have this available to the students at the start of the course so that they can work on it throughout 545B! There's always next year...

[vincenzocoia]

OK, here's a summary of where we're at.

Options

1. Do an assignment we give you about character data.
2. Improve your R package from Assignment 2-B.
3. Improve your shiny app from Assignment 3-B.
4. Contribute to the open source R community.

Ideas for the Rubrics

Option 2 + 3

This time, we'll be looking at design.

1. Describe the purpose of your app/package. Rubric based on usefulness and depth of purpose. ("depth" means that you need to seek out something more than the modest additions required by the original assignment -- but don't make this too ambitious so that you can't get it done in time!).
2. Design: is your app/package designed in a user-friendly way? Or are there some rough patches that interrupts the user's flow?

Option 4

Make 3 additions to the R community:

• A post on a Stack Overflow R question = 1 addition
• Reporting a bug or improvement request to an R package as a GitHub Issue in a clear and reproducible way = 1 addition
• Submitting a pull request to improve an R-related resource = 1 addition
  • Too small: something like fixing some typos in the R4DS book doesn't count
  • Too much: something like giving a complicated function like lm a facelift is far too much
  • Just right: adding a condition to throw an error message when a function ought to, and justifying it in the pull request.
• Delivering a presentation/seminar in a public/UBC R group = 3 additions (record it so we can see and evaluate your effectiveness of communication)

What now?

1. @vincenzocoia drafts a vision for a character data assignment. Perhaps drawing inspiration from the R4DS strings chapter.
2. @wvictor14 Can you provide some feedback on Options 2-4, specifically my ideas for the rubrics? Some things to watch out for: does anything look overly simplistic to you? Overly demanding? Not grade-able? Please do suggest improvements if you see any.
3. @wvictor14 A more high-level question -- is making an assignment like this overly ambitious? Should we dial it down a notch this year? Sometimes I just need a reality check.

[wvictor14]

Option 2 + 3

This time, we'll be looking at design.

Describe the purpose of your app/package. Rubric based on usefulness and depth of purpose. ("depth" means that you need to seek out something more than the modest additions required by the original assignment -- but don't make this too ambitious so that you can't get it done in time!). Design: is your app/package designed in a user-friendly way? Or are there some rough patches that interrupts the user's flow?

For the R package option at least, maybe we can require an informative README that describes and demonstrates their package. Things to include in this README would be like

• examples of package core functions execution
• examples of package demo execution
• some benchmark results

and we can evaluate them based on 1. the quality of the additional functions and/or code changes to existing functions, and 2. quality of the README

Some other ideas:

• What if we make them go through the process of what an update to an existing R package is like. For example, they could post an issue about an existing problem or challenge with the package, like missing functionality /features, bugs /errors, missing documentation. Then, they must create a PR (maybe multiple depending on number of unique issues) that address those issues. Lastly update the version.
• They can version/tag assignment 2b as v0.1.0 and then this assignment as v0.2.0. And we can evaluate their changes as well as how well they document these (major changes described in NEWS.md?).
• Maybe require turning their package into github pages if they haven't?

For the app, I feel like we could leave the idea of what is an "improvement" open-ended and let them decide? Then have somewhere where they can explain why it's an improvement and how they did so. Maybe in a PR, or in a tab in the app itself, or the readme on the github repo...

• We can make the evaluation more weighted towards effort and thoughtfulness than execution
• For marking, what if they keep the shiny app for assignment 3b deployed, but also deploy this updated 4b version so we can easily compare in side-by-side browser tabs (just easy for us to mark)

I like option 4, and it makes sense. But no one did bonus question 1.4 in assignment 1b (create a PR on an existing public R package). I feel like very few would feel able to do this option. I think many might just be intimidated by the idea? I feel contributing to "big name" packages like from tidyverse is a bit scary, maybe you can comment on this in class? But I think it's fine still to give them this option. Maybe mention it in next class, so that they have more time to search and find an R package to contribute / presentation opportunities?

[vincenzocoia]

Options 2 and 3: I wholeheartedly agree with all of those points, and think we should include them.

Option 4: I think you're right, nobody will do this without some sort of encouragement in class. Perhaps let's leave this for a future year.

@wvictor14 Are you able to bundle this info together into something that will eventually be student-facing? I'm still working on ideas for the strings assignment, but that will be done early this week.

[wvictor14]

OK I will try to make instructions and a rubric for options 2-4, and post something later this week!

[dy-lin]

Haven't read through this issue in detail yet, but one (basic) requirement for both the app and the package would be to implement feedback we have given them. Since the package was Assignment 2 and the app was Assignment 3, I think they should be able to get all the feedback in time for Assignment 5.

[wvictor14]

YEah that's a good idea @dy-lin , thanks for the suggestion. I don't think it should be a requirement though because some will not receive much or any feedback on their app. I can make it an option and provide alternatives though.

[dy-lin]

Yeah! The requirements I meant more like the feedback that requires fixing? (Eg inaccuracies)-- like for A2, for some reason a lot of students stated that their package is on CRAN, or wrong installation code (install.packages() instead of devtools::install_github())

[wvictor14]

Yeah I noticed that too! I'll put that down as an example

[vincenzocoia]

I don't think it should be a requirement though

There's something that doesn't sit right with me by not requiring implementation of feedback -- not good if they make an effective package/app with some fundamental flaws unchanged since last time.

But then, marks set aside for addressing feedback isn't adequate either, because not everyone will have things they need to change.

How about this: set aside a few marks for the package/app fundamentals according to the requirements of the original assignment. Yes, it's duplicating criteria from a past assignment, but it (1) allows for the possibility of someone making a new app/package as opposed to updating their previous, (2) allows them the opportunity to implement feedback, and (3) emphasizes the importance of having a fundamentally sound package/app. These marks are freebies if there's no feedback to implement, and they develop the same app/package without screwing up the foundation.

[wvictor14]

OK, sound good! Aiming to get something out tomorrow...

[wvictor14]

Hi @vincenzocoia , to clarify, you're working on option 1, the strings part of this assignment? So I will not touch that part and just focus on the other options 2-4?

[vincenzocoia]

So I will not touch that part and just focus on the other options 2-4?

I think so. I suspect I'll just take some open-ended questions from R4DS.