-
-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[REVIEW]: PsychoPhysioCollector #40
Comments
/ cc @openjournals/joss-reviewers - would anyone be willing to review this submission? If you would like to review this submission then please comment on this thread so that others know you're doing a review (so as not to duplicate effort). Something as simple as Reviewer instructions
Any questions, please ask for help by commenting on this issue! 🚀 Please note #41 looks to be a related submission. It may make sense to have both of these reviewed by the same individual. |
@openjournals/joss-editors - any suggestions for potential reviewers here? |
I pinged a friend that I think has the right expertise ... |
So you just need someone to answer the reviewer questions on this page for the PDF? Here on this issue? |
@davclark - basically yes. There's an associated GitHub repository (https://github.com/sbogutzky/PsychoPhysioCollector) which is the main focus of this review together with the short PDF. See our reviewer guidelines here http://joss.theoj.org/about#reviewer_guidelines If you think you might be able to help out, I'll add you to the |
Sounds doable. Go ahead and add me to the team :) |
@arfon do we verify that the license is enforceable? I.e., that the copyright holder indeed has copyright? @whedon I see you've copyrighted the work to yourself. If produced at an american university, this is often not legal - we need to assign copyright to the institution if we worked on it as a student. For free software, this is usually not a big deal - especially for a very liberal license. |
Cool stuff. This is important for social science research - and warrants a change in the language above from the JOSS review checklist:
Data collection is also part of science - much harder than analysis in many experiments. To this end, other guidelines are strained. What is the significance of "API documentation?" A few more notes:
|
While the above seems like a lot, I'd call this "minor revisions" modulo some clarification on the things that break the "analysis software" model - most critically that I can't actually test this on the biosensor hardware. |
@davclark - If you know of a reason why the author may have go this wrong then I think it's worth raising the question but we don't want to give legal advice to those submitting.
@davclark - @whedon is actually the bot that made the submission issue. @sbogutzky - this question is for you 😉 |
@davclark agreed and thanks for raising this point. Would you be willing to open an issue on https://github.com/openjournals/joss outlining your concerns with the language used in the checklist? |
Yes, this is right. tag 2.0.4 is the latest version of the PPC without the paper.
But you can test the basic functionality, because data will always collect from the internal sensors of the smartphone. In this way, you can for example track the arm motion of a participant with a sport armband while running.
So, you find the APK. See Installation Instructions of the readme.md
Ok.
See Used Libraries in the readme.md
Ok.
Ok, but this depends on the sensors and the configuration, which you use.
Maybe there are other solutions, but I these solutions do not support the hardware of our equipment.
E. g. if you place electrodes on the human body, you can check the leakage of the ECG based on the realtime visualization of the heart activity and the pattern of the signal.
Yes, of course, unfortunately the most is in german. There one paper of the beginning: "Gait Biometrics in Interaction Design: A Work in Progress Report" and presentation: "Analysis of ‚flow while walking and running’: psychophysiological correlates and activity-based results".
Is that needed? |
I think I may have inter-mixed some different kinds of issues above, so I'll respond to a few things again here. Let me also add that assuming it works (as I do), this is a very useful contribution. My comments are simply directed at making the publication / documentation better, and opening this up to more potential users and perhaps developers. Things that are up to the editorsThe things in this section will have no bearing on my recommendation.
I'm not sure if there are rules here, and I'll leave this to the editors. Seems better to have the paper in the tagged release, though.
This is in the guidelines for reviewers (emphasis mine):
As a reviewer, I feel my job is done by pointing out that this is not done. Things that are "mine"
I've opened openjournals/joss#156 on this point. Given the current discussion, I think we're gonna let the things I can't test slide.
It seems like there is either a disagreement or lack of understanding here. Let me give a more concrete example: I am at work with my fancy/annoying new macbook retina. To connect my phone, I need to unplug the hub from the single USB-C port, which means I need to rearrange my desk and move my ergo keyboard out of the way so I can plug into the USB-C port on my phone. I then grab the cable from the power adapter to connect my phone to my computer. The future is going to look more like this for more people. What I'm suggesting is easy enough that I just installed the APK by creating a
Those don't include https://developer.android.com/studio/index.html Compiling this would not be hard for most people with rudimentary development skills. You are not currently giving the basic pieces that would facilitate this.
Here is another solution. Why wouldn't I just use that? I can at least partially answer this question, but I'm asking you to at a minimum cite primary existing solutions in your paper per JOSS guidelines.
It seems there is no similar readout for phone sensors? Or am I missing something? I am able to verify the contents of the CSV files manually. Note that there is a slight type-o in your documentation. You mention
You should cite these - It doesn't hurt anything, and it facilitates discovery of your work! But I won't demand it. |
@davclark - First of all, that's for your feedback. @arfon - Now some questions to the editors.
Is there a rule?
I do not get it, sorry? Should I at the repo as webpage to the bib file and reference the entry in the paper? I do not see this in other paper of the journal. There, I see Paper DOI; Software repository and Software Archive. But these things will be added by the editors, right? After accepting? |
Sorry, there is a lack of understanding. What is the difference of my APK and your fork? In my case, I downloaded the APK from the repo and put it in my Google Drive or Dropbox folder and installed it on the smartphone. |
Ok. Right. This is a quite new solution of Shimmer for a newer type of IMUs. We began our studies in 2013 and build the existing solution for an older type of Shimmer IMUs (R2). These solution seems not to meet our requirements of mobility and automatic time synchronization of more data streams. A solution, which can you use, if you find it, is that: "Psychophysiological Correlates of Flow During Daily Activities" by Gaggioli et al. (2013)
No, because we worked in our studies primary with the Shimmer R2 IMUs.
That is right, I fixed it! |
@sbogutzky I am pretty sure at this point that I've communicated my concerns / recommendations - so please make any remaining revisions and I'll wait for you to tell me you're done. I'll also wait for @arfon or another editor to chime in on the questions for them. Regarding the google drive solution, that makes good sense. You've illustrated that there is a pretty easy way for individuals to install the APK without a wire. My solution was the same APK as yours, just providing a direct link from the github release page. I still think that'd be a nice-to-have, but I don't think this is required. |
@davclark - Thank for your recommendations. I'm ready with my revision. |
Looks good to me, and I hope the changes are helpful to others and (perhaps more importantly) for you substantiating this work as a genuine academic contribution. So as reviewer, I recommend acceptance. It's up to the editors about the verification issue described above (that I can't verify all functionality without the sensors), but I recommend the "low bar" of accepting based on verification "as possible" and trusting the authors for the rest (including evidence from the provided references in which this software was used with the sensors). Editors, please also note that the tag is updated to 2.0.5. |
Editors, please also note that change the title to "PsychoPhysioCollector: A Smartphone-Based Data Collection App for Psychophysiological Research" It is possible to change that on the Paper page? |
Thanks for the review @davclark and for being responsive @sbogutzky. Some responses to questions that have come up in this thread:
Ideally the release should include the paper but I don't think this is a hard rule right now. More important to me is that the release matches the version that has been archived (e.g. with Zenodo).
That's correct. The final version of the PDF will include a direct link to the software repository and the archive of the code.
This is now changed.
👍 |
@sbogutzky you paper is now accepted into JOSS and your DOI is http://dx.doi.org/10.21105/joss.00040 🎉 🚀 💥 Thanks for all of your help @davclark! |
Submitting author: @sbogutzky (Simon Bogutzky)
Repository: https://github.com/sbogutzky/PsychoPhysioCollector
Version: v2.0.5
Editor: @arfon
Reviewer: @davclark
Archive: 10.5281/zenodo.59387
Status
Status badge code:
Reviewer questions
Conflict of interest
General checks
Functionality
Documentation
Software paper
Paper PDF: 10.21105.joss.00040.pdf
paper.md
file include a list of authors with their affiliations?The text was updated successfully, but these errors were encountered: