Populate a `security_adjacencies` field in Participants

[andymeneely]

Currently, we have a field called security_experienced for participants. The field is a boolean for whether or not the person has, at the time of this code review, participated on the FIX of a vulnerability. Presumably, this means that this person would learn about thinking about security and start using that mindset in THIS code review. In our study, we found that files with more security experienced participants over time are less likely to have vulnerabilities in the future.

But what about knowledge transfer effects? For the participants in each code review, maybe they learned about security from someone else they've worked with who is security experienced. Let's measure that effect with this field.

Being "security adjacent" means that, at some point in the past, this participant has co-participated with another developer who was security-experienced at the time. We should count those security adjacencies and store them here. We can then add that up over time and do "security_adjacencies_per_review". Let's make it a distinct number of developers so two people working together doesn't keep stacking up.

For example:

Nobody has reviewed any security fixes
September 1st: Andy, and Alvaro co-review a security fix.
September 2nd: Andy and Danielle co-review a normal fix.
  Andy:
    security_experienced: true 
    security_adjacencies: 1 (Alvaro)
  Danielle:
    security_experienced: false
    security_adjacencies: 0 (not counting this one)
September 3rd: Kayla and Danielle co-review a normal fix:
  Kayla:
    security_experienced: false
    security_adjacencies: 0
  Danielle:
    security_experienced: false
    security_adjacencies: 1 (Andy)

After this, Kayla still won't gain security adjacencies until she co-reviews with someone who is security-experienced (i.e. two hops aren't counted)

September 4th: Alvaro and Danielle co-review a normal fix:
  Alvaro:
    security_experienced: true
    security_adjacencies: 1 (Andy)
  Danielle:
    security_experienced: false
    security_adjacencies: 1 (Andy)

September 5th: Kayla and Danielle co-review a normal fix again:
  Kayla:
    security_experienced: false
    security_adjacencies: 0
  Danielle:
    security_experienced: false
    security_adjacencies: 2 (Andy and Alvaro now)

To complete this, we need:

• Add the new field to the database
• Populate it in participants
• Populate a security_adjacencies_per_review field in release_filepaths
• Actual example data of this happening in our dev data. You'll probably need to find/craft some data for this
• Some verifies

[andymeneely]

@frauagrippa is also working on this

[andymeneely]

As we discussed in the meeting, feel free to elaborate on this metric idea and try out a few things. We'll have to narrow it down for a paper but let's explore the idea.

[andymeneely]

How are we doing on this? Anything worth pushing?

[SidIcarus]

Looking at this article as it seems quite related: Who is going to Mentor Newcomers in Open Source Projects? link: http://dl.acm.org/citation.cfm?id=2393647 pdf link: https://dibt.unimol.it/tools/YODA/resources/fse2012.pdf

[andymeneely]

Yep, I know that paper. Saw it presented in Szeged, Hungary two years ago :) They will be in our related work. They approached it a lot differently, but it's got a lot of the same ideas.

[SidIcarus]

That's pretty cool ;o I haven't read it yet; would it be worth the read or not / beneficial to read?

[andymeneely]

This was done last week, but I need to integrate it into the nightly build.