Replication Data and Codes

[sammo3182]

Guide

The corresponding author will be responsible for preparing and submitting materials outlined in the conditional acceptance letter to the APSR Dataverse. See additional instructions below.

• The Dataverse materials should be cited in the main text of the article or letter at the location when their content is first referenced (usually at the beginning of the section describing the methods of data collection) and the complete citation for the Dataverse materials should be included in the reference list.
• The corresponding author will need to provide the DOI of the Dataverse materials in Editorial Manager where submitting the final manuscript files.

1. Provide documentation to explain the organization of files and their contents, such as:

   • A Readme text file that provides key study information and explanation of all the other files in the Dataverse;
   • A copy of the Supplemental Information appendix uploaded to Editorial Manager;
   • Any additional appendices indicated in your letter of conditional acceptance (e.g., interview guides, survey question wording, ethics information, etc.); and/or
   • A codebook or data dictionary for all variables used in the study.

2. Use a consistent file naming system.

3. Make sure data and command script files are complete, including:

   • Clearly indicate which software version(s), including package(s), were used in the analysis;
   • Include scripts for data cleaning and variable transformations;
   • Give variables meaningful names;
   • Add comments to your code to explain what code should do; and
   • Include all the code and/or data files necessary to reproduce all tables and figures in the published article or letter as well as all analyses referenced in the text (e.g., footnotes or figure notes) or in the Supplemental Materials.

• [x] A readme file
• [x] Codes: software and package version
• [x] Codes: proper comments
• [ ] Replicable data, uploaded to the APSR Dataverse (see the details in the guide)
• [ ] Citation of the replicable data with DOI

[Tyhcass]

@fsolt As to replication data for dcpo, could you please also create dcpo_output by using data/dcpo_input_raw.csv (https://osf.io/cz2ta/) at your end, just in case it will take so long for me to attain output? I've tried iterations 1000, 1500,2000, but I am not sure how long it will take to produce output given my student account at HPC. Thanks.

[fsolt]

@Tyhcass Okay, I'm puzzled. (1) This new OSF dcpo_input_raw.csv isn't any different from the one on GitHub. (2) dcpo_input_raw.csv isn't actually what ever gets input to dcpo, that's dcpo_input.rda. The difference between the objects dcpo_input_raw and dcpo_input is that dcpo_input_raw hasn't yet been scrubbed of countries with fewer than two observations, and it isn't in the format that dcpo expects--but the code for doing those things isn't our document (dcpo_input_raw doesn't appear in dcpo_demsupport.Rmd at all, in fact). So: (a) why is dcpo_input_raw.csv now on OSF? (b) is dcpo_input_update22.rda (ugh--this is what git is for) what we're using for input now? and, sigh, (c) why isn't all the code in the document?

[fsolt]

I see that the answer to (b) is yes. I've committed it to the repo

[Tyhcass]

@fsolt As to "This new OSF dcpo_input_raw.csv isn't any different from the one on GitHub." Yes, there is no difference between them. The problem is that dcpo_output was not produced by dcpo_input created by dcpo_input_raw. Due to the version problems in HPC, I never had a dcpo_output. So, the dcpo_output we used was created at your end. However, I guess the dcpo_input used for creating dcpo_output was not dcpo_input_raw, since the number of countries was less than expanded data. I don't which parts caused the differences. Therefore, to make sure that we are on the same page, it might be better to start with creating input from dcpo_input_raw. That is why I didn't suggest that we should dcpo_input_update22.rda directly. Instead, you might want to create input at your end.

As to dcpo_input_update22.rda, yes, I created it via file R/dcpo_input.R. Actually, in R/argon/, we haven't had codes for dcpo_outputs.

[fsolt]

Thanks for the clarification, @Tyhcass. As I've been saying, the way to ensure we are always on the same page is to have all the code in the dcpo_demsupport.Rmd document.

[Tyhcass]

Hi, @fsolt @sammo3182 I want to double-check several things on codes. @fsolt said that we should include all codes in dcpo_demsupport.Rmd document.

1. Do all codes include codes that created our analysis data? Our analysis data is a huge list containing 900 datasets of main IVs, DV, and controls?
2. Do we need to include codes for creating latent variables and controls?
3. Do you mean that we will put dcpo_demsupport.Rmd directly on APSR Dataverse?

Personally, I feel it will be easier for readers to replicate from our analysis data. If they want to run the replication code in full, they can use R codes to create analysis data from scratch. If it is the case, for readme.file, I just need to describe file structure for creating analysis data, since other codes are in the Rmd file. Is that right?

[Tyhcass]

@fsolt I did not see codes to estimate public support from expanded data using Claassens' M5 or our DCPO. I think that claassen_m5_rep.R in R/argon/dcpo_demsupport_rep is the R code used for creating measures from corrected data. Could you please upload codes for creating measures from expanded data?

[fsolt]

The file you're looking for, the one that uses the expanded data, is R/argon/dcpo_demsupport/processing.R. I just updated it with the correct number of iterations (2k) here and to show depo_input_update22 😬 here. Its output is now on OSF as church_lb2_2k_02-23-02-19.rda. This file has always included both dcpo_output and dcpo_input to (try to) ensure that things always line up.

[Tyhcass]

Thanks, @fsolt ! Could you please let me know where the code file for creating output from expanded data is? When I have all three files (for replication, expanded data, and dcpo), I will put them into one folder.