Skip to content
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

IRB approval #41

Open
kcranston opened this issue Oct 23, 2015 · 4 comments
Open

IRB approval #41

kcranston opened this issue Oct 23, 2015 · 4 comments

Comments

@kcranston
Copy link
Member

kcranston commented Oct 23, 2015

Karen to talk to Duke IRB about what we need to do. Assuming:

  • we will need IRB approval for this manuscript
  • we might be able to get a waiver from asking each participant for permission to publish stats on publicly-available content (participant lists, github handles, twitter handles, etc)
  • we will not pubilsh demographic data except as summary statistics
@aidanbudd
Copy link
Contributor

Karen, thanks again for dealing with the IRB for us on this stuff.

I thought it might be useful to make a notes of the things we could be asking the IRB about, in terms of the data, and analyses, we might want to publish, that we think it might be relevant for them to look at.

Data we could publish:

  • list of github handles, twitter handles, events they were part of. That's what others would need, to analyse the impact of the event on the activity of those people and combine it with their own similar data. Real names, projects they're involved in, wouldn't be so useful for others to integrate with their own data, in my opinion.
  • list of the repos that were worked on during the project. This may also be worth mentioning to the IRB, as there may also here be identifiability issues i.e. you just check which users have contributed to which repos in a particular time (i.e. during the events) and you can see who they were, particularly if they've given their real name in their handles.

Analysis we could publish:

  • activity (in number of commits) for repos before, during, after the event
    • how many have continued to be developed long after the event? (evidence of event contributing to development of valuable software resources)
  • networks of Twitter/github interactions before, during, after an event
    • were any of the interactions that were created during the event sustained for a long time afterwards? (evidence of event building long-term relationships)
  • pattern of usage of github before, during, after the events
    • were there any people who joined github just before/during the event, and who became habitual users of the resource? (evidence for benefit of the hackathons in getting people to use and then adopt important technologies)

(In the future, I'd recommend collecting ORCIDs - even if they are currently problematic, I expect one day we'll all use them, would allow retrospective analysis in terms of co-publication before and after the events.)

When writing to the participants, perhaps mention that the lists of people participating in the events are freely available on the internet. Thus, the data and analysis we're suggesting we publish, could be assembled by others. What we're asking for permission to do (in terms of privacy and identifiability) is making it easier for others to find these things out, as they can see them just by reading our publication, not having to do the analysis themselves.

Let's also, if we write to them, ask them to confirm we have the correct github and Twitter handles for them.

@arlin
Copy link
Contributor

arlin commented Jan 9, 2016

I also have to do an IRB-like review with NIST. They do not allow any other organization to do the review.

@arlin
Copy link
Contributor

arlin commented Apr 25, 2016

my impression is that we are too late. NESCent has closed its doors, and there was no provision in the original consent for research uses. The privacy policy says relatively clearly that consent will be obtained to use information for purposes other than internal analysis of effectiveness and reporting to NSF. We are not proposing to do either of those things, Furthermore, we are not even NESCent, which doesn't exist. So, I think we can't use the NEAD data. We can either (1) forget doing anything with diversity data, (2) forget about ethnicity but assign genders ourselves, (3) re-contact participants to obtain the diversity information with a proper consent form.

@hlapp
Copy link
Member

hlapp commented Apr 25, 2016

I'm not worried about NESCent having closed meaning we aren't NESCent. (Our past affiliations with and support from NESCent don't vanish with NESCent's existence ending. Also, by virtue of NSF rules for grant receiving institutions, there continue to be people responsible for stewarding the data, who can thus be asked or consulted.) However, the point about the privacy policy taking the place of the consent form if there is no consent form I agree with. This is compounded by the problem of small numbers, meaning for certain categories of diversity (especially any ethnicity other than non-white caucasian) the chance of inadvertent de-anonymization even for summarized data is high.

@arlin arlin assigned arlin and unassigned kcranston Jul 23, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants