Can we group developers and files into teams using OWNERS files?

[andymeneely]

@rikal owns this, but @dani5447 is familiar with this material. This is a new crazy idea, however, that we did not approach at all last year.

Perhaps we can conduct analyses of developer teams instead of filepaths? For example, our data points in our analysis are currently release_filepaths. Maybe we can conduct our analysis at the team level, where metrics like number of vulnerabilities or bugs can be measured for the team.

However, due to the hierarchical nature of OWNERS files, I'm curious how we can group developers together.

For this, in conjunction with #181, let's brainstorm some ways we can potentially label both releasefilepaths and developers on certain teams and then conduct analysis that way.

[dani5447]

Brainstorming Notes from 9/9 Meeting with @rikal :

• Investigate change in OWNERS files, track their teams/relationships.
• Look into if churn/high turnover in an OWNERS file introduces more vulnerabilities to that directory.
• Graph number of people over time in a team, number of commits over time for a team

[dani5447]

Are these teams of everyone in general, or just teams of OWNERS for now?

• We can group OWNERS by the filepath their name is on, but we can't really group developers in general by saying 'this person made a commit here, they must be on this team.' (Could have vagabond developers.) We could come up with a threshold number of commits on a filepath to say they belong to a team, but what amount would be appropriate? @andymeneely any thoughts on this?
  • Going off this, a cool metric would be % commits by vagabond developers, compared to num CVEs, compared to team size on the filepath?? (not sure about comparing to team size)

Some rough initial metrics concepts: - to review with @rikal at meeting

• num CVEs/bugs compared to team size - we would assume a bigger team leads to more problems, right?
• avg num review participants from a "sister team" - how much do teams cross-pollinate? aka how often do members of a "sister team" participate on the other team's reviews, and do they introduce more knowledge -> is their knowledge helpful or misleading?
  • This could relate to transfer of knowledge, sharing of bugs/issues/CVEs, etc.
• % commits on a filepath by a member of a "sister team"
  • compare this with number of CVEs on this path - is it higher or lower than an average? That is to say, does a developer from a sister team bring in more complementary knowledge, or do they introduce more vulnerability because they are not as intimately familiar with the files?
• avg num review participants from a "parent team"
  • How often does a member of a team one level up in the file structure participate in a review? -- is this useful?
• % commits on a filepath by a member of a "parent team" - same concept as the % commits on filepath by sister team members
• num CVEs and bugs on a team compared with num sheriffs and num OWNERs - do having people with OWNER/sheriff expertise reduce CVEs/bugs
• team developer churn on num CVEs/bugs