I agree! All I meant to say is that it’s really out of pattern with everything else a new person is learning to do. More than once I’ve seen people struggle even when they’ve been told exactly the steps to take, and I think it’s because what they’re being asked to do is almost taboo compared to regular practice — people seem to sort of unconsciously reject the instructions.
The non-reproducibility is also a challenge because people can’t simply copy and paste the code that goes along with dput() instructions. They have to read carefully to catch the crucial step. My ideal instructions would call out all of these stumbling blocks and make liberal use of illustrations to show the process.
Anyway, this is getting pretty far off topic, so if we want to discuss dput() further, we should probably take it to another thread!
Right. I realized that I have been off topic a lot since I (bad, bad me) did not read the title and first post of the thread carefully (at all)... So sorry Andrea for missing the point about the "two specific steps" all along...
But to sum up a few (off topic ) things, I like the idea of scheme and illustrations and I think that a summary post (in a new thread linking to all the old threads on reprex) might make things less overwhelming in the face of growing info on the topic. And the key points about a reprex seem to me to be:
1. makes sense without being run
So includes input and output. Not everybody wants to run the code.
2. can be run
The essence of "reproducible" and a necessity to test suggested solutions.
3. does not contain sensitive or personal data
Those should be anonymised or fake data of similar structure should be created.
4. does not use data which needs to be downloaded
The data should be created from the script text, either from code producing it or from dput() output.
5. (optionally) does not contain more than is necessary to reproduce the error
For the added sleekness of a minimal reproducible example. But that is more sophisticated and not necessary.
I would parrot what's already been said, and encourage you to start new threads in #meta on FAQ guides you think we are missing, and what you are thinking. I've been thinking about this stuff for a while and would be happy to contribute.
And if you or anyone else wrote this up on your personal blog and/or recorded video, we'd be happy to highlight it here.
Even if these are just more focused versions of existing guides/FAQs, it could be of value as a perfect link to give people at the right time, (and another thing for Google to deliver given the appropriate search).
In terms of reprex content we are lacking, I see the following:
On data for a reprex
I agree that it's probably time to coalase notes in
A list, very organized set of copy-paste examples of options (the value of str, how to use dput, readr::read_csv/read.csv with file and with text, tibble::tribble, wrapr::draw_frame, datapasta::tribble_paste, file-system linking to a CSV file or other file.).
A longer video walking through these examples, geared toward those new to coding.
Common reprex errors
It seems there are a small set of common errors people run into when doing reprex. It might be nice to have a wiki to deposit those error and start creating FAQ solutions? E.g. "you don't actually load the reprex package in your reprex..." and "file system file loading".
Shiny reprex stuff
Barret, Mine and others are working on improving this, but if you have suggestions, that would be awesome! The big issues being around shiny-debugging, shiny-reprex, debugging shiny deployment issues, and using rstudio.cloud for your shiny-reprex.
@Andrea, would you like me to close this thread start any of these under your username?
Hi @EconomiCurtis, ok, let's close this thread: you can open one under my name concerning data for reprex. I'll probably not record a video because recording videos takes too much time for me, but I'd be happy to condensate the two threads you mentioned in a simple wiki.