Hackathon Preparation

[daniel1noble]

• [x] Google Form for Data Collection - @itchyshin @mlagisz and @daniel1noble
• [x] Google Sheet for Participants and Co-authors - @daniel1noble
• [x] Co-authorship Expectations Document - @daniel1noble
• [X] Setup Zoom Link - @daniel1noble

[mlagisz]

@daniel1noble @itchyshin Draft google form almost ready (need to discuss a few points). I pre-piloted it on 3 preprints and it took around 10 minutes per preprint. PCI recommendations might be hard to find - unless you have already figured out how to do it quickly. Final preprint version number is in Excel, so maybe we dont need to check this manually?

[mlagisz]

Do we plan to register the survey on OSF? e.g. as a one-page document with the aims and outline of the approach?

[daniel1noble]

Thanks @mlagisz ! I looked at the form and made some edits. Let me know what you think. The PCI recommendation should be fairly easy. I've added details on how to do that in the question description. I think if everyone follows that same approach it will be fine. Yes, should try and do the pre-registration. Will see if I can find some time before but not sure if I will. Either way, I can create a release of the whole GitHub repo and call it "plan" so it's clear what we initially intended to do before data collection.

[mlagisz]

Thanks @daniel1noble. Good additions! I made some minor edits too. A found a few other things I suggest to consider now:

• I think for the information which is usually collected by copying and pasting we should not ask for "All lower case letters". This adds extra extraction time due to having change letters manually after pasting (and it is safer to copy and paste names rather than typing text in manually which in turn introduces many typing errors, while changing to lowercase is so easy in R).
• I changed "Submitting_author_first_publication_year" recommendation for coding authors without GScholar profile to 0, because this field is validated as an integer number, so it will not accept "NA".
• For the "value required" fields Data_link_preprint and Code_link_preprint, I suggest explicitly asking for entering "NA" if the preprint is not and empirical or equivalent article based on data and data analyses (so usually for opinions, comments, narrative reviews, theoretical paper, etc.) and asking to enter "none" if the link is not there but article is based on data/code. Alternatively, we can change both these fields to "value not required" status, but then we cannot tell apart the reasons for having blank values (no link).
• Blind_review is a journal-level information and as such could be extracted later only once per journal, which will save time at this extraction step (same applies to any other journal-level information).

[daniel1noble]

Thanks @mlagisz All great suggestions! So, let's run with them. I agree. I didn't realise I put "lower" case for copy and paste and completely agree we shouldn't. Journal stuff I thought we would collect as I suspect we will have lots of different journals, but you're right we can wait on that one as it will save time. Nice! Thanks so much again!

[mlagisz]

@daniel1noble, I added more clarifications to the extraction instructions on the Google Form. I also pilot-extracted another preprint - it took me 15min. I also edited a bit the README file, but did not sync the data fields descriptions with instructions from the GoogleForm, as they serve different purpose and do not need to be identical. I recommend and adding the aims from the manuscript to the README file. After the final check, we can either do HGitHub release version for this as a "protocol", or even better, rendering this file and uploading to OSF as an Open Format registration (takes 5min).

[daniel1noble]

Awesome! Thanks @mlagisz. I didn't know about the OSF Open Format registration. Let's just do that. I'll still make a release to take a snapshot so we have it all on GitHub anyway too.